Re^6: Update the GUI (What we want?)

[LanX]

Problem is we are discussing (at least) three different questions here

a) Design

b) Usability

c) Cleaning up / Modernizing the code base

Regarding...

... a Design

Most visitors here are passive and silent and just read. And IMHO is PM alone responsible for a huge part of Perl's web presence.

So improving the design should be priority, and something like TobyInk's solution proves that it can be without changing the code base (even with a responsive design for mobiles).

... b Usability

Toby's solution is also changing the UI somehow, this by parsing and relocating buttons and menus.

And I agree that this could be facilitated by changing / adding some CSS classes. But this too can be done without revolutionizing the code with just some little patches. °

... c Modernizing

In theory the migration to a new code base with real MVC separation (Catalyst, Mojolicious, ... ) would be beneficial, but I don't see this happening soon (or rather never). ²

update

fixed "mobile" typos

footnotes

°) I'm already using several private nodelet hacks to improve my mobile experience

²) Probably you are aware of problems I don't know about ... (for me this looks like a Perl6-like generation project).

[Your Mother]

I agree. For my personal perspective, as a potential volunteer, c blocks a and b. If a job is even 10% harder than it absolutely needs to be, I'm'a complain about it. I think without c, a and especially b (Ajax voting, readily available data, tagging system, all the things that make StackOverflow pleasant), is more than 10% harder.

With the state of JS today, you could essentially do a complete rewrite of the site using the backend as little more than a data store but you'd be constrained to the schema, the encoding quirks, the sub-HTML rules, and more, I'm sure.

The reason I come here is the community and culture as much as the expertise and this is a text based profession so, again personally, I don't care that much about the design and old-fashioned UI. Some monk with reading difficulty is going to assert I said nothing should be done. I didn't. I'd love a revamped site. I just don't volunteer others for jobs I'm unwilling to do.

[LanX]

Hey

Thanks. I'm not trying to "volunteer" you, I just prefer to (over ;) analyze a project before getting involved!

So questioning you're reasoning results in more informations. ..

Not sure what

• Ajax voting, (why should this be hard?)
• readily available data, (?)
• tagging system, (well we have tags. ..)
• the schema, (can't tell)
• the encoding quirks, (?)
• the sub-HTML rules, (???) °
• and more,

Actually mean in detail, but my primary concern is the visual representation of the Perl community. (Updated some comments out of curiosity )

Compare Metacpan to Cpan, just the visual impression.

I haven't seen a modern responsive design yet without JS, and JS is a good mean to get people involved who don't dare reading all Tolstoy's developer wiki. ;)

Though I have to say your ...

> If a job is even 10% harder than it absolutely needs to be,

... reasoning sounds like a perfect justification to abandon Perl 5 and to wait til 6 is ready. :b

°) are sub-html rules followed by sub-humans? ;-p

update

Added comments to list of deficiencies

[Your Mother]

• Ajax voting, (why should this be hard?)
  • There is no REST interface; pretty sure. Writing a JS interface overlaid on a legacy HTML interface is possible but *terribly* verbose and not fun at all.
• readily available data, (?)
  • SO publishes tons of sliced data on questions and answers. This doesn't exist in PM. Backend changes would be necessary to make it reasonable.
• tagging system, (well we have tags. ..)
  • Questions are always and trivially tagged and untagged in SO. The tagging system here is completely free form and not useful as it stands.
• the schema, (can't tell)
  • Like above. If the data isn't in the DB and the DB makes it torturous or a serious performance problem... the JS has to mimic/map a database to a brand new (virtual/in-browser) database.
• the encoding quirks, (?)
  • UTF-8 is not supported correctly here. Try putting "ಠ_ಠ" into code tags. :P Or just a post and see how it comes back in the edit/update <textarea/>.
• the sub-HTML rules, (???) °
  • The rules for posts do not allow real HTML but a mini-version based on 1999 HTML standards that allows things like <code/> tags.

Compare Metacpan to Cpan, just the visual impression.

Metacpan is just a better site. "Design" is not all that different. Information layout is, which some might call design. What is different: API, social linking features, code viewing, availability of tools, search works better, responsiveness of developers, so much information above the fold, mobile docs, dev activity charts. So, basically all the kinds of things I'd like at PM that range from difficult to impossible as is stands. :P

> If a job is even 10% harder than it absolutely needs to be... reasoning sounds like a perfect justification to abandon Perl 5 and to wait til 6 is ready. :b

Perl6 is today, and for the foreseeable future, more than 10% harder. I'm interested in Perl6 succeeding but for now I am still a Perl5 fanmunk.

And I would be first in line to volunteer for a Perl5 rewrite of PM. I would participate in a Perl6 rewrite too but less enthusiastically just because so far it's less fun (doc, bugs, speed).