Long Term / KDE.org Design Update

[Ken Vermette]

Wagh! Sorry I haven't been more active here; my day job has had me on heavy
web development for the past few months - you can imagine programming PHP
for more than 8 hours a day can send some people screaming to non-web
projects, especially when it's not a quick project like the KDE websites. ;)

In all honesty my progress was starry-eyed and a bit crap, I haven't been
satisfied with my work at all, and for some reason I thought writing
(another) custom CMS was a good idea; I came back to what I had yesterday
and set the project folders on fire. Aside from some pretty designs and
inconsequential HTML, I'm going to reset my progress meter, because I doubt
the whole "lone wolf" thing will get very far on a long-term project like
this - especially since my screwups would be your burden - and that thought
stressed me out.

I think the most important thing isn't the design aspect, but having a
solid foundational CMS which is modern, will be updated, and will allow for
easier management. I'd like to maybe just start with your feedback as the
maintainers; right now KDE.org has several systems its running under,
including Capacity as a sort of "glue" CMS... I'd like to poll you guys on
the possibility of picking and sticking with one CMS, even if it means
programming a multitude of modules, which I'm willing to do. I also think
it's important that you guys choose what you want to maintain, because
what's easy to design for isn't necessarily what's easy to maintain.

I'm also thinking "not custom" since keeping things up-to-date is a tough
issue, but with something like Drupal or Wordpress at least we know it will
have active maintainers dedicated to the main codebase. If we can just
maintain modules in a skinnable multi-language system that will be half the
battle won forever and ever. Hopefully, for user-facing pages we'll get our
core codebase down to CMS X and PhpBB.

Anyway!

I think the first thing I'd like to hear from you guys before I re-kick my
efforts is; do you agree with my logic, and what CMS would you prefer to
maintain if you do?


On Fri, Jul 10, 2015 at 2:23 AM, Andrej Mernik <andrejm at ubuntu.si> wrote:

> Dne 08. 07. 2015 ob 23:43 je Albert Astals Cid zapisal(a):
>
>  El Dimecres, 8 de juliol de 2015, a les 10:33:57, Andrej Mernik va
>> escriure:
>>
>>> Hello Everyone;
>>>>
>>>> My name is Ken Vermette, I'm a member of the VDG and by trade a web
>>>> designer/developer. We're interested in modernising the kde.org
>>>> websites
>>>> and getting the ball rolling on better unifying the sites as a whole.
>>>> I'm
>>>> personally willing (and expecting) to invest the time and programming
>>>> effort required to do this. I know it's obvious, but we'd also like to
>>>> work
>>>> closely with the web team.
>>>>
>>>> It's a huge undertaking and we know it will easily take years to finish
>>>> all
>>>> the sites; we would like to know we aren't stepping on toes, duplicating
>>>> existing efforts, etc. Before any of that we need the green-light from
>>>> here, and would also like to invite web-team participation in building a
>>>> maintainable and more universal kde.org network.
>>>>
>>>> Thank you, and great work;
>>>>
>>>>    - Ken Vermette
>>>>
>>> Hi all,
>>>
>>> I think a redesign of the kde.org sites is a great idea. Since
>>> responsive
>>> design is now a "must have", I suggest building the site upon one of the
>>> responsive frameworks (for example Bootstrap) rather than building a own
>>> responsive framework. Also the new design should be more consistent.
>>> There
>>> is no need for inline CSS as it makes overriding hard, the same thing
>>> also
>>> holds for internal <style> tags.
>>>
>>> Although design is important, there is a component that desperately
>>> needs a
>>> rewrite: the backend.
>>>
>>> I have been digging through code in an attempt to customize one of the
>>> kde
>>> pages and it was not a pleasant sight. The main problem of the current
>>> design is that a lot of things are hardcoded. Basically, if you include
>>> the
>>> header.inc file, you are stuck with all the things that other sites have.
>>> This might be good for the normal websites, but as soon as you have to
>>> customize a thing (for example add/remove a css file or a div), you are
>>> out
>>> of luck. There is no easy way to override things, but with minor tweaks
>>> this could be achievable, without breaking things.
>>>
>>> My proposition is to split the hardcoded content into modules loadable
>>> by a
>>> loading function:
>>>
>>> // pseudo code
>>> function load_module($type, $file, $allow_override = false) {
>>> if $allow_override == true
>>>     // look into the current script directory for $file and include it if
>>> found, return else
>>>     // look into $type for the $file, include it if found, return
>>> }
>>>
>>> example header.inc:
>>>
>>> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
>>>       "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
>>> <html xmlns="http://www.w3.org/1999/xhtml"  lang="<?php print
>>> $site_locale;
>>> ?>" xml:lang="<?php print $site_locale; ?>"> <head>
>>>     <title><?php print $title; ?></title>
>>>
>>>     load_module($document_root, 'meta.inc', false); // meta is loaded but
>>> cannot be overridden load_module($template_path, 'css.inc', true); css
>>> can
>>> be overridden by a local css.inc file load_module($document_root,
>>> 'js.inc',
>>> true); js can be overridden by a local js.inc file
>>>
>>>    ...
>>> </head>
>>> <body>
>>>     load_module($document_root, 'breadcrumbs.inc', true); breadcrumbs
>>> can be
>>> overridden by a local breadcrumbs.inc file load_module($document_root,
>>> 'plasmaMenu.inc', true); menu can be overridden by a local plasmaMenu.inc
>>> file
>>>
>>>     etc.
>>>
>>> This is (somewhat) the same mechanism that Wordpress child themes use and
>>> it's really easy to use.
>>>
>>> The second problem with the backend is that it's outdated. If you turn on
>>> error reporting and warnings on a server with recent PHP version, the
>>> number of messages will blow your mind :). If there is redesigning being
>>> done, why not update the backend to current standards? The current
>>> backend
>>> does a good job, but sooner or later it will have to be modernized.
>>>
>>> Anyway, these are some things I have noticed by browsing the code. I
>>> would
>>> be happy to help improving the frontend/backend, so I'm wondering what is
>>> the current status of the redesign.
>>>
>> I don't know if anyone is still working on a big redesign for kde.org
>> but if
>> you have patches for capacity to make it more modular we can totally have
>> a
>> look at them :)
>>
>> Cheers,
>>    Albert
>>
>>  I would be happy to do things, however, I would really like to see what
> has been done until now (if anything). I would also like that the VDG
> participates in this, so we can plan how the future theme should be
> structured. I really don't know if it's wise to change the current theme,
> since some sites depending on it's structure might break. Opinions on this?
>
>
> Cheers,
> Andrej
> _______________________________________________
> kde-www mailing list
> kde-www at kde.org
> https://mail.kde.org/mailman/listinfo/kde-www
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-www/attachments/20150713/8dd51be7/attachment.html>