[Mageia-discuss] Website software

Wed Sep 22 01:09:20 CEST 2010

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
+