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

[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).

[LanX]

thanks, just some remarks (more to come)

> There is no REST interface; pretty sure.

Some ppl wrote plenty of xml tickers, some of those even needing authorization.

Adding a new vote-interface shouldn't be harder, unless I'm missing something.

See What XML generators are currently available on PerlMonks?

> Perl6 is today, and for the foreseeable future, ...

Sorry not my point, it was meant as analogy. There is no Meta-Perlmonks available today.

We didn't stop continuing Perl5 development 15 years ago because of the prospect of a better tool to come, which is 10% better. (Well some did)

We (except you ;) should continue developing PM too.

> Metacpan is just a better site. "Design" is not all that different. Information layout is, which some might call design.

I agree from the perspective of the experienced Perl user.

Most visitors probably aren't and will judge their "Perl xyx" search hits after 500 ms by the colors and fonts.

My priority ATM is to improve this impression, not to compete with SO (yet)

[Your Mother]

The reason why I think it's a terrible way to go about it is it completely violates good web app design concerns. It uses the View and the Model and half of the Controller as a TERRIBLE API to construct a new view, a new hybrid model which consumes the view and the model and turns it into a new model, and new controllers which have to account for all this mess to create a new, more reasonable, interface. It's possible, sure, and if someone smarter than I am can show how to do it well, I'd rejoice and sing hosannas. I've been doing this awhile though and CSS improvements, like what tobyink did, and perhaps some Ajax voting are about as much as could be expected and it wouldn't be super easy and would (probably) still require user action to add the CSS and JS manually. Therefore this would be of zero use to newcomers and casual visitors... If the Gods determine the scripts/CSS are safe enough to implement in the actual site delivery, maybe... I would never advise anyone to build out technical debt though. I wouldn't try to stop them to strongly either. :P

The core of what this site is/does is quite basic and if just a couple of monks with the chops committed to it, it would be done in 6 months. Less if bikeshedding could be avoided.

[Anonymous Monk]

Adding a new vote-interface shouldn't be harder, unless I'm missing something.

Its very trivial to add :)

As in its done Re: Perlmonks AJAX Voting (greasemonkey plugin)