[Mageia-discuss] Website software

Wed Sep 22 03:08:52 CEST 2010

Le 2010-09-21 19:09, Romain d'Alverny a écrit :
+> On Mon, Sep 20, 2010 at 05:11, Diego Bello<dbello at gmail.com>  wrote:
+>> I think Romain has a lot to say here.
+>>
+>> He knows the needs of the current Mandriva site so he can say
+>> if the best option is a CMS or a custom developed site (Symfony anybody?).
+>
+> Well, yes and no. I can mostly relate what choice has been made at the time.
+>
+> We got several experiences with some CMSes that were not so good in that:
+>   - web team was way too small to master the whole thing;
+>   - editing pages was restricted by a limited set of templates;
+> especially, a CMS could now allow to edit inline HTML, so fine-tuning
+> the contents layout was a no-go;
+>   - its ease-of-use for non-technical people was supposed to distribute
+> editorial responsibility within the organization; in fact, very few
+> people did it themselves, rather sent a mail to the webteam to
+> integrate an open office document;
+>   - its ease-of-use was too to help for translation process; that was
+> partly true, it helped yes, to some extent (too small a team being the
+> culprit, he, but making this way harder to manage in the end);
+>   - no dedicated or available skills to maintain it (so many nightmares
+> to fix common issues or upgrading it);
+>   - performance issues under heavy loads;
+>   - no apparent content strategy from one migration to the other
+> (broken links&  redirection all around; missing contents; inconsistent
+> design across the whole domain, etc. but that's another topic, yet).
+>
+> Not that I am complaining. These were great times and there were lots
+> of good things to learn from these CMSes too (maybe not stable enough
+> at the time or not properly mastered) but that was what was
+> experienced. Goal was to improve on this.
+>
+>> I think the most important feature here is internationalization, cause
+>> Mageia really needs to show itself to the world, and let me tell you
+>> the world doesn't speak English only.
+>
+> Indeed. Now you have to take into account several things:
+>   - you've got to decide whether you use a pivot language content tree
+> or leave several language trees evolve on their own; that is, having a
+> reference from which you translate/adapt everything, the process being
+> more or less fast depending on your translation team; or, having an
+> mutual agreement between all editors, and moving each language tree to
+> its own pace; for a start, I would suggest the former (ie, having a
+> reference tree to translate from), then adapt;
+>   - translating, better, localizing a web site is not about only
+> translating chunks of text; you sometimes need to rework pictures,
+> labels, layouts, add/remove specific contents; so it may require
+> several basic webmastering skills (editing HTML, working on graphics,
+> understanding and coding CSS, bits of Javascript and so on);
+>   - you've got to decide if you strive for a standard-looking website
+> or if you want to apply a specific look and be able to fine-tune
+> everything; again, that depends on your "global" web team capacity of
+> production and maintenance;
+>   - coordination of the localization process of the website is a huge
+> task in itself;
+>   - all your website does not necessarily have to rely on a single
+> solution; you can have a blog platform here, a static set of files
+> there, a drupal over there, a forum here, ad-hoc download platform
+> there, etc. it really depends on several parameters;
+>   - questions to ask are: what does Mageia do? why? how do we organize
+> all this information? who produces/uses it? what should be the
+> user/visitor experience/goal? what's the best tool for that?
+>
+>
+> Now, back at the time (it was first drafter in early 2007 and went
+> into prod in the fall of 2008), I wrote a very basic "decorator" web
+> framework that let me build and design standalone HTML/PHP pages
+> (against a set of CSS rules and a minimalist theme, to be revamped
+> later with a graphics designer - didn't happen, sadly) in the old-way:
+> files and directories. All this was versioned on a SVN (crucial part
+> of the system) to allow for collaborative webmastering (I wouldn't
+> call that editing as, again, it's not just updating chunks of text).
+>
+> This was only for the main "institutional" website (aka www/www2)
+> where things are pretty static (a big update every 2 months or so,
+> plus gradual improvements in the meantime). Around this connected a
+> blog, a news feed (that could have been a blog), forums, wiki,
+> support, download, e-commerce platforms, etc.
+>
+> It was far from perfect of course, but it was valid and working in
+> that context and back at the time because:
+>   - content was mostly static; few areas needed to have dynamic
+> behaviour, and when it did, a small ad-hoc webapps system was
+> available to take on that job;
+>   - so you didn't really benefit from having a database;
+>   - it proved effective for deploying a standard look to most of the
+> distinct platforms, all from a single web service (top nav bar + basic
+> CSS rules);
+>   - présupposé was that only webmaster-skilled people would manipulate
+> it; and it would keep it away from people that would not care at all
+> about the website global consistency (about information architecture,
+> design, navigation, localization, content strategy, etc.); that was
+> part of my job, actually;
+>   - experience with Blogdrake translation team proved it more fluent
+> than a conventional CMS (or so I thought), although there were lots of
+> improvements to do (especially in direction and how we would have
+> proceeded);
+>   - there were interesting improvements to find (because, well, it's
+> not an "ideal" solution), like, setting up a mixed templating system
+> to help formatting standard pages across all locales;
+>   - and in the end, because I felt more confident with a minimalist
+> solution I could understand and manage with other translators than a
+> big thing I couldn't;
+>   - and it wasn't as stupid as that as other big web projects seemed to
+> use a similar solution (which I learned through discussions that I
+> freely inspired from too) for parts of their website.
+>
+> That was unpublished code, unfortunately (although it was in my
+> plans), so I can't publish it. But I can redraft it, as it's pretty an
+> easy architecture to reproduce and code is not that big. Most of the
+> work is still, well, in how you design and build your website. No tool
+> will write a good story for you.
+>
+> Now, things may be slightly different:
+>   - I won't manage websites directly, but most likely coordinate and delegate;
+>   - you certainly have better ideas.
+>
+> Sorry to be so long (ah, don't start me with that topic! ;-) ), just
+> to state what I learned and think is important to take into account.
+> You may want to use something like that too (or not).
+>
+> Cheers!
+>
+> Romain
+
+Merci de ton explication Romain. Are you then going to be involved with 
+the web design of the site(s)?
+
+Marc
+
+