User:Protnet/Frontend for Vector skin CSS customizations

Frontend for Vector skin CSS customizations

Public URL: https://www.mediawiki.org/wiki/User:Protnet/Frontend_for_Vector_skin_CSS_customizations
Bugzilla report: bug 62899
Announcement: http://lists.wikimedia.org/pipermail/wikitech-l/2014-March/075399.html

Name and contact information

Name: Ioannis Protonotarios
Email: ioannis@protonotarios.eu
IRC or IM networks/handle(s): protnet on irc.freenode.net
Web Page / Blog / Microblog / Portfolio: My business website (Greek): http://office.protonotarios.eu
My personal blog-like wiki (Greek/English): http://meta.protonotarios.eu
Location: Athens, Greece
Typical working hours: 8:00-15:00 (till mid-June), 9:00-13:00 & 18:00-24:00 (July, August) (EET)

Synopsis

Abstract

Appearance is most important for any site. Unfortunately, while MediaWiki is very advanced in functionality it lacks flexibility in terms of appearance. Vector skin is great, no doubt about it, but it seems there is no other alternative. Almost all wikis in the world look like Wikipedia. Of course one can apply their own CSS and customize the site's layout or even create their own skin in PHP but both solutions demand a lot of knowledge and effort and in the end nobody really does so except maybe for some big commercial sites.

My proposal is the creation of a frontend that will help users with little or no experience at all to easily produce all the CSS needed to change their wiki's layout.

Proposal

Vector skin is now a mature skin and along with its many enhancements is by far the default, if not the only choice for modern wikis.

Therefore, the creation of a new skin, besides the fact that is a difficult process for anyone, will only take them back to the start and also miss all the fancy and functional enhancements Vector has. Instead, one with lots of CSS knowledge, can manipulate the styling of Vector skin and make a wiki "template" out of it that may resemble nothing to the original skin but be closer to a Wordpress or a Joomla template. With CSS it's easy to hide unnecessary components such as menus, tabs, logos etc, or move them to othes positions or even tranform them to some other component type (for example tabs can be transformed to a drop down menu).

The idea of using CSS is the wiki way because:

CSS is stored on a wiki page,
- and thus can be accessible by any (i.e. manipulations can be transparent and easily reused to other wikis).
Registered users can create or use their own template by using their personal CSS page.
Different user groups can have different templates via the user groups CSS pages.

An example of the latter can be found in my personal blog-like wiki. For this particular site I wanted to make a template where visitors would see no tabs, or menus, and on the other hand, wiki admins would see the full wiki page components and be able to edit and navigate to special pages. This was done by adding some hide commands to page MediaWiki:Common.css and undoing them in MediaWiki:Group-sysop.css.


visitor's view	admin's view

Part of the problem is that Vector skin lacks a proper map of the positions of all its components, like the ones can easily be found in Joomla templates. See for example, the latest Joomla 3 Protostar template map. In our case the Vector skin map should be more detailed with a complete list of all the CSS classes and subclasses and their default values employed by the original skin.

Having the map is a good start to begin customizing the layout but one should be an expert in CSS to make something worthy.

The idea is to create a frontend that would do the job instead.

The frontend itself could be:

a standalone program,
a standalone web page, or
a MediaWiki extension

The frontend inteface could be either:

Text, or
Graphical

How it works

The user, using either text or graphical interface, after making the desired changes has the option to preview the new layout on their wiki.

If the user has finished editing the layout can then save the changes. What the program does then is that it creates the desired CSS code and appends it to the appropriate CSS pages of the wiki, depending on the user selection and rights. For instance, if the user is an admin, they have the option to apply the new layout to the whole wiki, or to a specific user group or just for this user.

So the whole idea is that the program creates the code for you.

In many ways it resembles the way that all those free online CSS3 generators work (like for example this one). The main difference is that it also applies the changes with a single click.

More than just layout

Having an interface that creates CSS code, it's easy then to add more features. So, via the frontend the user also has the ability to:

Change the wiki's font using Google or other web fonts
Note on fonts: Due to MediaWiki's security restrictions it's not possible to load a font from a different site, i.e. google.com via the CSS pages. Therefore fonts must have been uploaded locally.
Change colors of
- text
- backrounds (site, content etc)
- lines
Enchance titles and boxes with CSS3 effects (shadow, curvy rectangles etc)
Apply images to backrounds

A step further would be to be able to create new classes for various other elements such as tables, divs etc.

Examples

Example 1

The text interface will look as follows but with many more settings, arranged in sections.

In this example we see the section where one can change article titles attributes.

User types the desired values in assorted text boxes.

In this example a GUI will look pretty much the same for those settings but will have many improvents in functionality. In some cases they'll have the ability to select instead of typing. For instance, one can click on color button next to color text box and a JS color picker appears. Or other clicks may lead to open a drop down list. For instance, Google font name may be selected from a list of all fonts installed instead of typed in.

A GUI may also have an instant preview of the result that this particular settings have. For example, this section (Article titles) may have a preview of just the title. Other sections may have their own previews.

In either text or graphical interface user then presses Preview to preview changes in their actual site and if satisfied presses Apply to make changes permanent.

Technical

In this example what the frontend does is that it appends the following code to page MediaWiki:Vector.css:

/* Code added by extension X */
/* DO NOT EDIT BEYOND THIS LINE */
@font-face {
  font-family: "Ubuntu";
  font-style: normal;
  font-weight: 400;
  src: local("Ubuntu"), url("../fonts/Ubuntu.woff") format("woff");
}
h1 {
  font-family: Ubuntu, sans-serif;
  color: white;
  font-size: 250% !important;
  text-shadow: 0 1px 0 #ccc,
               0 2px 0 #c9c9c9,
               0 3px 0 #bbb,
               0 4px 0 #b9b9b9,
               0 5px 0 #aaa,
               0 6px 1px rgba(0,0,0,.1),
               0 0 5px rgba(0,0,0,.1),
               0 1px 3px rgba(0,0,0,.3),
               0 3px 5px rgba(0,0,0,.2),
               0 5px 10px rgba(0,0,0,.25),
               0 10px 10px rgba(0,0,0,.2),
               0 20px 20px rgba(0,0,0,.15);
}

Result

Article titles will now look like this:

Example 1.1

In sections like the above there may be dropdown lists with readymade or saved sets of settings one can select from instead of starting from scratch. A list of readymade article titles could be right next to the above panel and might look like this:

When user selects one of these then the new values occupy the text boxes on the left and might be further attuned.

Further improvements

Saving settings

In order for the user to be able to re-edit their custom layout, settings must be saved.

In its simplest form, the interface stores all settings as XML in a special wiki page (in a similar way as the extension Page Schemas does). More specificaly, the user is asked to provide a name for the settings and then the frontend creates a special settings page with that name. When user wants to edit a layout is given a list of all pages with saved settings to chose from which to edit.

Sample XML used for saving settings

<Template name="My Skin 1">
    <AllUsers>
        <Font>
            <Name>OpenSans</Name>
            <Size>15px</Size>
            <LineHeight>20px</LineHeight>
            <Color>#333</Color>
        </Font>
        <Tabs>
            <Hide/>
        </Tabs>
    </AllUsers>
    <Group name="Sysop">
        <Tabs>
            <Show/>
        </Tabs>
    </Group>
</Template>

Retrieving current layout

A more difficult approach would be for the frontend to get current settings directly from the CSS pages. This involves the danger that those pages may have been altered manually with custom CSS code not recognizable by the frontend. So the challenge here is first to parse the CSS and get all recognizeable settings from, and second, leave not recognizable settings intact. I will not intend to go near this.

Possible mentors: Not found any yet. If interested please let me know.

Deliverables

I will go for the extension as it solves more problems than it creates.

Required

A MediaWiki extension that
- is accessed via a special page
- using text interface (with text boxes for various values), in order to manipulate:
  - element positioning (selected from a number of predefind layouts)
  - element sizes and metrics
  - background colors
  - backround images
  - text styles (with CSS3 text effects)
  - box styles (with CSS3 box effects)
- stores saved "templates" in its own DB table
- implements a custom ResourceLoader module to output the custom CSS
- is fully internationalized
5 sample "templates"

Optional

If time permits:

Give user the ability to add a custom JS menu to their templates (and maybe some other modules)
Give user the ability to upload web fonts
Make the extension extensible for new skins
- Simple way: The extension supports other skins but is updated manually for every new skin
- Advanced: People making skins are able to hook into the extension, and add new things to customize
Create a GUI with functionalities such as:
- drag n drop
- resize
- right click context menus
- color pickers
- visual dropdown lists with readymade sets of settings
- instant previews in specific sections

Proposal Timeline (under construction)

Before April 20:

To familiarize myself with git
Study some php, create some test hello-world extensions

April 20 – May 23 (Before the official coding time):

Request the creation of the git repository on MediaWiki.org
Community bonding.
- In constant touch with mentor and community.
- Remain active on IRC and Mailling lists to discuss and finalize on the modifications (if any) that needs to be on existing schemas and design of new schemas.

May 23 – June 23 (Official coding period starts):

Have initial directory structure and files in place
Add initial ResourceLoader support
Add proper internationalization (i18n) support

June 23 – June 27:

Mid term evaluation

June 28 – July 15:

Code review, design discussion and whatever unexpected things might come up.
Making further changes in the code to improve the Functionality, Exception handling, Bug Removal.

July 15 – July 25:

Most of the time will be consumed for rigorous testing and bug fixes.
General codebase cleanup
Try to document the parts of the codebase that haven't been documented by this point

July 28

Make sure that the output is valid HTML (on a vanilla MW installation with no funky extensions installed)
Write developer and end-user documentation on MediaWiki.org

August 4

Final code reviews and codebase polishing in accordance with code review comments.

August 11

Tie up the loose ends, in case if there are any of those.

Participation

This is a personal idea I have since last year that came out of the need to de-wikify the appearence of my wikis, at first. I have done a lot of CSS modifications since and I think I understand the way things work and what needs to be done. Unfortunatelly I found out about this years applications to GSoC very late (5 days before expiration) so I haven't had the time to properly discuss this with the community and find mentors and even prepare a decent proposal. But this is an area I have given it a lot of work and thought for a long time so I think it will be easy to reach my goals and even more.

As a regular user of MediaWiki with lots of questions, bug reports, ideas for improvement, simple patches etc I am in touch with the community for quite a long now and I know where and how to get help with this project. I understand that most participants will also have help from their institutions and fellow students which I won't since I now study education but I think that this won't be a problem since this project is rather simple yet very effective and more than coding skills what it needs is imagination and a wide area of understanding of wikis.

I have the habbit of logging everything when coding so I plan to publish daily reports of my progress to my user page in MediaWiki and weekly reports to wikitech-l mailing list. I will also be availiable on irc #mediawiki.

I will use a local environment for running MediaWiki for development and will be committing to gerrit every new feature as long as it's ready.

About you

Education completed: Electrical & computer engineer MSc.

Education in progress: Currently a student in post-secondary level (though irrelevant to IT - I study education) while waiting to start my second master's in IT coming October.

How did you hear about this program?: I knew about this program from various extensions I have used in the past but I heared about this year's applications from a friend in Greek Wikipedia.

Will you have any other time commitments, such as school work, another job, planned vacation, etc., during the duration of the program?: I have school till mid June but only during the evenings. I also work but as a free-lance engineer so I am able not to undertake any jobs during the summer which is a dead period anyway for my line of work.

We advise all candidates eligible to Google Summer of Code and FOSS Outreach Program for Women to apply for both programs. Are you planning to apply to both programs and, if so, with what organization(s)?: No

Past experience

Please describe your experience with any other FOSS projects as a user and as a contributor: I am a proud FOSS user and supporter for many years. As a contibutor I have done many little things in many projects. The last 3 years I have focused mainly on MediaWiki when I setup my first wiki. I now maintain 7 live semantic wikis on various subjects. This forced me to get my hands dirty and start dealing with bugs, coding, patches etc. I have not yet created a complete extension (well maybe a hello-world-ish one) but I have succesfully moded a couple of those. In terms of Semantic MediaWiki I have created complex ontologies (and more complex templates to support them). Last but not least I am an active Mediawiki translator and I have translated most of semantic extensions to Greek myself. I have also created a MediaWiki glossary and many translation guidelines. As a wikipedian I have started a Greek Wikipedia Education Program focused on adult education.

Please describe any relevant projects that you have worked on previously and what knowledge you gained from working on them (include links)

What project(s) are you interested in (these can be in the same or different organizations)?: My main interest is MediaWiki, Semantic MediaWiki along with some major extensions such as Semantic Forms, Semantic Maps etc, as well as the Translate extension and on the other hand CSS capabilities in site design. That's why I couldn't resist and tried to apply to both areas.

Another topic that I am very interested in is duplicate image finding. My thesis was on image processing and I have done some personal research on this but for the moment I'll stick with wikis.

Any other info

css3 is fun