Reading/Web/Desktop Improvements/Nicks Hack Results

Summary

The Reader's Web team had a hack week on the week of Aug 12, 2019 in an effort to compare development of a collapsible sidebar using a fork of the vector skin and a collapsible sidebar using the minerva skin (containing the same links as the vector sidebar) in preparation for our Desktop Improvements project. Having very limited experience working with the Vector skin (or more precisely a fork of the Vector skin), I was curious to investigate what that experience was like. Therefore, from the span of Aug 13 (the day our team started the experiment) - Aug 15 (I was out of town the last two days of the hack week) I focused on making a fork of the Vector skin have a collapsible sidebar and look a bit more like what our team has envisioned the UI of the final project to look like. Because of this limited time, I chose to focus mostly on changing Vector's CSS styles and see how far I could get with that.

Here are the steps I followed:

1. Literally copied the vector directory and named it "Epidermis"
2. Replaced all references of "vector" with "epidermis" in the new "Epidermis" directory
3. Adjusted some of the structure of the html (e.g. moving logo from sidebar to header), added a bit of js for toggling the sidebar, but mostly added styles

Results

Here is a link to the source code of the project with an animated gif of the final result:

https://github.com/nicholasray/Epidermis

Screenshots can be viewed at https://github.com/nicholasray/Epidermis/tree/master/screenshots

Conclusions and Takeaways

• Mainly, I was pleasantly surprised how far ~200 lines of CSS styles and minimal changes to the structure of Vector could get to the UI of the desired mock. Furthermore and FWIW, because the Minerva skin doesn't currently have all of the links that Vector's sidebar menu has, I don't believe that I would be able to achieve the same result as quickly (and definitely not with mostly CSS styles) had I done this experiment in Minerva. On the flip side, Minerva is a responsive skin and although Vector has a config setting to increase its responsiveness, extra work would be required to match the responsiveness of Minerva.
• Part of the reason I named this skin "Epidermis" is that I knew I would really only be scratching the surface of mediawiki skin development with this project (and because I wanted to see a file named SkinEpidermis.php in the MW codebase). Although I was pleasantly surprised at how far CSS styles can go with the Vector skin, I realize that there is a lot of untested stuff that could still break (e.g. compatibility with gadgets and other extensions).
• For the sake of time, I used CSS such as Flexbox to style this skin. However, this may or may not (probably not) be compatible with our desired device support. Not using conveniences such as this would probably make this task take considerably longer.
• When strictly considering the code inside the "vector" folder, the size of the codebase is enticingly small. However it relies on a large number of dependencies (e.g. mediawiki.searchSuggest, etc). This differs from the Minerva/MobileFrontend codebase in that many dependencies of MF/Minerva are included in the repo. For example, MobileFrontend includes its own responsive component library (overlay, drawer, button, icon, etc) which Minerva uses.

Areas needing improvement

Although, both of these points are a lot easier said than done, I really think we should strive to improve at least one of the following areas when tackling the desktop improvements project regardless of the baseline we start out with:

• The current Skin framework relies heavily on inheritance, hooks that use references as params, and it has been said that the HTML output that skins produce needs to be as similar as possible to maintain compatibility with extensions and gadgets . This can lead to very brittle skin implementations that are resistant to change.
• The components that make up skins (e.g. search widget, tabs widget, hamburger menu, buttons) should be more standardized, responsive, configurable, and reusable. Currently, skin authors have a choice to use OOUI widgets and widgets from core. However, for various reasons, custom rewrites of widgets still happen. For example, Jon pointed out that the portals page, vector skin, and minerva skin all use a different search widget even though the portals page search widget and minerva skin widget have a nearly identical UI. This leads to a proliferation of code and maintenance. Ideally, I think skins should mainly be a collection of styles and be composed of widgets from one standardized component library. Skin authors should mostly be pulling from this component library when constructing their skin.