Closed Bug 793403 Opened 7 years ago Closed 6 years ago

Sandstone skin for wiki.m.o

Categories

(Infrastructure & Operations :: IT-Managed Tools, task)

task
Not set

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: pierros, Assigned: nikos)

References

Details

(Whiteboard: [kanban:https://kanbanize.com/ctrl_board/4/81] )

Hello,

Wiki.m.o needs some Sandstone love :) Nikos, leo and me are committed to build a new skin for mediawiki based on Sandstone. This is the story so far:

- We started setting up a dev server in mzlwiki.hackerspace.gr. Tried to modify existing skins but proved to be impossible as many of the elements of existing skins are positioned "absolute"

- We started a new skin (Sandstone) and will import all basic Sandstone assets in it (LESS, background, LESScss etc)

A request we have for the Design team is: Where we can find the sandstone mixins and fonts to download them.

Also we would love feedback and sign off once we have something to be reviewed. Thanks!
For various projects (such as mozilla.org.uk), I've taken the sandstone files out of the bedrock repo [1].

Just stick an import at the top (like here [2]) and go from there! (Personally, I replace the fonts.less file with the css import from the Google Fonts API)

[1] https://github.com/mozilla/bedrock/tree/master/media/css/sandstone
[2] https://github.com/mozilla/bedrock/blob/master/media/css/sandstone-guide.less
Hi Pierros. There's a series of pages starting at http://www.mozilla.org/en-US/styleguide/websites/sandstone/ that should be of help.

Beyond that, this might be a better question for folks on the web prod team.
hi there.  Can we close this bug based on comment #2?  Pierros?
The style guide is great but unfortunately it doesn't contain the actual resources (css files, fonts, etc). Anyway, we took Leo's advice and took them out of the bedrock project.

You can re-assign the bug to me, since we are working on developing the skin. Please feel free to move it to the relevant section if needed.
Thanks Nikos, what would be the relevant section? It would no longer be a design bug but i'm not sure what component to assign this to with your name.  thoughts?
Hey Tara and Nikos!

I would keep it here for now, so we can get the final Design sign off, once we have it complete.

Then we can open a bug in WebProd for deployment.
sounds good, thanks.
Assignee: tshahian → comzeradd
Status: NEW → ASSIGNED
Hey there,

This is what we came up with:
http://mzlwiki.hackerspace.gr/index.php/Main_Page

Still working on the responsiveness as LESS grid is not the most automated grid in the world :)

What do you think?
Really nice work!
Hey there,

How can we polish this more and deploy it ultimately?
Pierros, whose call is that?
John, I have honestly no idea. We need to find the owner of the wiki I guess. Any pointers? I couldn't find it as a module...
Unfortunately I really don't know. You have the green light from me, but I'm not sure that really amounts to all that much in this context!
Maybe we should transfer it to Websites -> wiki.m.o
Component: Design → wiki.mozilla.org
Product: Marketing → Websites
Component: wiki.mozilla.org → Server Operations: Web Operations
Product: Websites → mozilla.org
QA Contact: nmaul
Version: unspecified → other
Moved this to WevOps for review.
Can we take this as a commitment from webdev to actively maintain our mediawiki skin(s)? :)

I ask that partly in jest, but also with a serious undertone. A lack of web developer support has been a major impediment in wikimo's evolution for at least the past 2 years. I'm honestly not terribly interested in adding yet another custom skin without such a commitment. This means watching the relevant Bugzilla component(s), fixing bugs, coordinating with IT for code pushes and core MW upgrades, etc.

If we can't or don't want to do that, we should be reverting to the stock Vector or Monobook skins.


Assuming we're willing to really support this, we'll need to know the code repo where this lives. :)



As far as making it the default, I don't think we can *start* there. However, we can probably make it an option and tell people about it, and if feedback is good then flip over to it as the default at some point.

One hurdle still to overcome is getting a sec-review signoff. They'll definitely need the code, and frequently also want to see it in action somewhere (your demo site in comment 8 might be sufficient).
Flags: sec-review?
We could help on that. I'm not part of the webdev teeam, but along with Pierros we can maintain the wiki skin. We have a long time experience with Mediawiki.

Source code of the sandstone skin we made:
https://github.com/comzeradd/mediawiki-sandstone

The php part it's actually pretty much similar to the current (gmo) skin of wiki.m.o., as we found it on mozilla's github.
Flags: sec-review? → sec-review?(curtisk)
:dveditz - this one was assigned wile I was on a work week, was this assigned to me to get a group review?
Flags: needinfo?(dveditz)
No, more for scheduling. We need to find someone to review the PHP code involved and you should know who's most available (and knows PHP).
Flags: needinfo?(dveditz)
Flags: sec-review?(curtisk) → sec-review?(fbraun)
Can we get this on a staging/dev server? I'm a bit unsure about a few things mediawiki and this would speed the review up.
ok, I think I understand most of the code but I have troubles sorting out which variables originate from user input and which do not. Especially, I have no idea where the $data array comes from and what its content is. The mediawiki docs mention it but all links at https://doc.wikimedia.org/mediawiki-core/master/php/html/classQuickTemplate.html#aa57c4e88fcaaf78905479d41036c4f18 point to a 404.

Could you please provide a pointer where to look for additional information about $data? :)
Flags: needinfo?(comzeradd)
As I understand this, it's an array of attributes that the skin returns (actually the QuickTemplate class):
https://www.mediawiki.org/wiki/Manual:Skinning

We didn't play much with this part of the code to be honest, because it's actually identical with the one at the current wiki.m.o skin:
https://github.com/mozilla/mediawiki-skins-gmo/blob/master/skins/gmo.php
Flags: needinfo?(comzeradd)
Thanks, this helped a bit but didn't rid me of all doubts.
I would like to test this on a dev/staging server, if possible.
I have deployed this to wiki-dev.allizom.org. Log in, go to your preferences, and choose "Sandstone" as your default skin. You can also just append "?useskin=sandstone" to any URL and it should render that page in the Sandstone skin.


A few comments...

1) Some pages look quite nasty. Example: https://wiki-dev.allizom.org/WeeklyUpdates/2013-03-11?useskin=gmo is okay, but https://wiki-dev.allizom.org/WeeklyUpdates/2013-03-11?useskin=sandstone is not so nice. This is a great example page, because it's one the whole company sees regularly, and uses several different elements. The 3 biggest things I notice are: Table of Contents, underlining on header sections, and lack of table borders under Speakers / New Hires. The first is clearly a problem, the other 2 are more stylistic and maybe not a problem.

2) Some content is hard-coded to http://. These should be changed to https://... or better yet, protocol-relative URLs.

3) Text scaling seems to be confused. Looking back at the page in #1, note how the breadcrumb text is bigger than the next line under GMO, but they're the same size in Sandstone (in fact the next line might even be bigger!). I don't know how widespread this is, I just noticed that one thing, because it drew focus to something that previously was less emphasized. Vector, Cavendish, and Monobook don't seem to show breadcrumbs, so it's hard to tell what's the better design here. In fact, given the breadcrumbs in GMO/Sandstone, I'd venture to say the next line isn't even useful. Not sure if it can be removed.

4) GMO feels wide, whereas Sandstone feels narrow. Sandstone might work better on narrower displays (seems like it always wraps, never side-scrolls), but GMO definitely feels better on wide displays (it wraps if you get very narrow, but expands nicely as the display widens). When looking at Sandstone, I feel like I'm only using about 1/2 my display, and have lots of dead space. This is enough for me personally that I'd probably not use Sandstone.

5) Like GMO, the Preferences page isn't tabbed. If possible, it would be really nice if this could work like it does in Vector and Monobook. Compare: https://wiki-dev.allizom.org/Special:Preferences?useskin=vector https://wiki-dev.allizom.org/Special:Preferences?useskin=sandstone. This is not a new thing... GMO and Cavendish both have this problem as well. Just mentioning it in the hopes that we could make Sandstone better in this respect, instead of merely equivalent. :)
I forgot to mention... this skin generally looks pretty awesome. The inclusion of Tabzilla at the top is a particularly nice touch. Good work!

A good chunk of things, especially the Main Page, look off in GMO, and even more off in Sandstone. I suspect this is frequently due to *poor page design* and should rightly be fixed in the page code, not the skin.


One more thing I just noticed:

6) In Vector, there's a very spartan toolbar above the "Edit" content box when editing a page. In GMO and Sandstone, this doesn't appear. Any theories? This is another pre-existing thing that would be nice to get fixed in Sandstone, just to make it better than GMO. :)
In general, headline size in relation to text size seems a bit to big, e.g. https://wiki-dev.allizom.org/Main_Page?useskin=sandstone
Jake's comments sound like there is some more work need on this theme. Should I defer the sec-review further to wait until the last bits are sorted out?
Please do Fredy! Nikos and I are working on fixing those.
Thanks for the quick response. Please request another sec review, when done ;)
Flags: sec-review?(fbraun)
I think I'll finally find the time to address these issues :)

We just happened to notice that there is a "Sandstone" option on Appearance settings currently on the wiki. Is this the template we are developing? If that's on a github repo it would be nice, so we can push the modifications through a Pull Request.
It looks like somebody addressed the font issues and it got deployed to wiki.m.o *without* the security review.
Somebody please update this bug and bug 859856 accordingly..
Flags: needinfo?(comzeradd)
Did we find the skin's github repo that's being used for deployment? It would be easier to to PRs for fixing some bugs.
Any news on that?
Flags: needinfo?(comzeradd)
Component: Server Operations: Web Operations → WebOps: Other
Product: mozilla.org → Infrastructure & Operations
I am confused. What's the status and why isn't it tracked in bugzilla? -.-
Flags: needinfo?(pierros)
I am confused too. We need to find who/why/when pushed to prod
Flags: needinfo?(pierros)
OK, on another note. What is the status of the skin itself and is it actually *done* and ready to be reviewed? :)
05:38:23 < freddyb> is there an easy way to zip up the skin that is on the production server so pierros can diff it?
05:41:24 < freddyb> can you zip it and send in an email to fbraun, cc Pierros Papadeas

Done.
> Hello Daniel and Fred,
> The tar seems to have been created the 23rd of April. Are we sure that
> this is the same that is live in production?
> If that's the case then this is the exact same as the one we created with Nikos.
> Let me know,
> ~Pierros

Yes, that is what is in production right now, and yes, the directories and files were created on 23 April 2013.
Whiteboard: [kanban:https://kanbanize.com/ctrl_board/4/81]
We are going to maintain styling changes on top of Vector to replicate the Sandstone look, rather than implement an entirely new skin. This will be handled entirely through the MediaWiki interface.

For more information, see our announcement:

https://wiki.mozilla.org/MozillaWiki:News/2014-08/Upgrade_to_MediaWiki_1.23
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
Component: WebOps: Other → WebOps: IT-Managed Tools
You need to log in before you can comment on or make changes to this bug.