Long Term / KDE.org Design Update

Sat Jul 11 14:14:13 UTC 2015

El Divendres, 10 de juliol de 2015, a les 08:23:11, Andrej Mernik va escriure:
> 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?

I didn't say change the current theme, i said "make it more modular" so it can 
be easier/better reused for stuff like you did in the events page.

Cheers,
  Albert

> 
> Cheers,
> Andrej
> _______________________________________________
> kde-www mailing list
> kde-www at kde.org
> https://mail.kde.org/mailman/listinfo/kde-www