Design

design@lists.wikimedia.org

604 discussions

Re: [Design] [Wikitech-l] Question: Should wikimedia wikis such as wikipedia be updated with a user frendly desgn
by S Page 10 Sep '15

10 Sep '15

(adding Design list) On Wed, Sep 9, 2015 at 9:06 AM, Magnus Manske <magnusmanske(a)googlemail.com> wrote: > Whatever happened to Winter? It's not coming, AFAICT... > Yes. See the "Winter" thread on the design mailing list: https://lists.wikimedia.org/pipermail/design/2015-July/thread.html There are three avenues for appearance development * User JS+CSS and gadgets. * Iterate on Vector as Beta features (sadly "Compact personal bar" and "Fixed header" are no longer offered as Beta Features due to bugs). * Prototype and refine new skins. Regards, > On Wed, Sep 9, 2015 at 2:58 PM Ricordisamoa <ricordisamoa(a)openmailbox.org> > wrote: > > > There is some work about getting the mobile skin on desktop (T71366 > > <https://phabricator.wikimedia.org/T71366>), and Blueprint > > <https://www.mediawiki.org/wiki/Skin:Blueprint> powers the Living Style > > Guide. > > However, no matter how ancient Vector may look, the little updates it > > has received over the years make me think it isn't that bad for those > > who use it. > > > > Il 08/09/2015 19:53, Thomas Mulhall ha scritto: > > > Hi this is a question but shoulden Wikimedia wikis such as Wikipedia > > be updated with a user friendly design. Currently vector is coming out of > > date because now a days you see sites with bruitiful colours not old ones > > as they were in 2010 when vector came out. We could create another skin > to > > replace vector as we did with monobook or update vector with a new look > > that has bold colours and goes along with mediawiki code and is also > mobile > > optimised even though we have the mobilefrontend extension some users may > > not want to install instead hoping the skin is mobile optimised. > -- =S Page WMF Tech writer

1 0

The Hamburger Menu Doesn't Work
by Ori Livneh 11 Aug '15

11 Aug '15

The Hamburger Menu Doesn't Work It's a beautiful, elegant solution that gets it all wrong, and it's time to move on http://deep.design/the-hamburger-menu/

5 5

Winter
by Amir E. Aharoni 29 Jul '15

29 Jul '15

Does anybody remember Winter? - http://unicorn.wmflabs.org/winter/ Brandon's designs made a lot of sense and looked like a much-needed refreshment of what should be MediaWiki's default skin, but now a few months after he left the project appears to be in limbo. Is there any intention to follow up on that or to start new work in that area? -- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com ‪“We're living in pieces, I want to live in peace.” – T. Moore‬

19 38

Xerox PARC talk about Vector in 2010 (Re: Winter)
by Rob Lanphier 29 Jul '15

29 Jul '15

On Tue, Jul 28, 2015 at 5:28 AM, Liam Wyatt <liamwyatt(a)gmail.com> wrote: > TL;DR - Objectively measurable criteria. Clear process. No surprises. > > The context of my giving the example of Vector as a good example *of > process* was after the presentation about the future of 'Flow' at > Wikimania.[1] I highly recommend people read the slides of this session if > you've not already - great stuff![2] In particular, I was talking about how > the Usability Initiative team were the first to use an opt-in Beta process > at the WMF. It was the use of iterative development, progressive rollout, > and closed-loop feedback that made their work a successful *process*. I > wasn't talking about the Vector skin per-se > [...] > And I DO remember the process, and the significance that was attached to > it by the team (which included Trevor Parscal), because in 2009 I > interviewed the whole team in person for the Wikipedia Weekly podcast.[4] > [...] > [4] Sorry - I can't find the file anymore though. This was the page: > https://en.wikipedia.org/wiki/Wikipedia:WikipediaWeekly/Episode76 > Liam, great response! You gave me a great excuse to weigh in with a little story of my own experience with the rollout, and a link to a video. In 2010, I had long been an active Wikipedian, albeit never nearly as active as many of the more famous around here. However, I was a brand new contractor hoping to get hired by WMF. I was living in Seattle, and *frequently* flying down to San Francisco because WMF hadn't learned yet how to have anyone doing anything remotely management-related as a remote employee. On my first(?) working trip to the San Francisco office, I got the chance to go to a talk given in at Xerox PARC by Tomasz Finc, Eugene Kim, and Trevor Parscal <http://www.parc.com/event/1108/how-wikimedia-is-scaling-open-source-innovat…>. We all piled into Priyanka Dhanda's car, and she drove us down to Palo Alto. I was very impressed with how WMF was thinking about it at the time. Maybe it was my rose-tinted glasses being a new guy, but I had spent enough time trying to make single-vendor, commercially-driven open source work <http://www.oscon.com/oscon2008/public/schedule/detail/4400>, that I was giddy to be working at a place where there was a significant and thriving community behind the development of the software. WMF had many problems with it's paid/unpaid developer relationship (see the "[Foundation-l] Community, collaboration, and cognitive biases" <https://lists.wikimedia.org/pipermail/foundation-l/2010-June/059052.html> thread started by Erik Möller and my participation in it <https://lists.wikimedia.org/pipermail/foundation-l/2010-June/059097.html> to see my thinking on it), but those problems were *interesting* in a way that I had gotten tired of dealing with in corporate open source. At that time in general, many in the office practically seemed to have PTSD with respect to their community interactions. I can't blame them. We hadn't learned nearly as much as we know now about to speak publicly about what we're doing. We're clearly not perfect now, but we had a 5 years less experience, and a fraction of the people involved. Employees were *expected* to be as productive as their commercial counterparts, and communicate far more broadly about their daily activity, with far less structure and support from the organization. That's not meant as a knock on the people that were employed here back then; they worked hard and heroically. It's also not a knock on the volunteers who worked (and continue to work) tirelessly to deal with the issues created in supporting such a huge set of sites without the tools. budget and day job available to their paid counterparts at commercial websites. We're all trying to do something really hard. There are lessons to be learned from commercial counterparts, but let's not beat ourselves up too badly for not coming out of the gate at their level. I haven't gone back and watched it to see how impressed I am now, but Liam is almost certainly correct. There was some great thinking happening there, and in particular, I think Trevor's talk about the Vector rollout may be a good proxy for the interview that Liam is referring to. See the video for yourself: PARC Forum: How Wikimedia is scaling open source innovation <http://www.parc.com/event/1108/how-wikimedia-is-scaling-open-source-innovat…> Thanks for cc'ing me Jonathan, I wouldn't have seen this otherwise. > Note: I had to explicitly add Liam (again) on this response due to reply-to munging here. At the risk of thread hijacking, I suggest everyone tempted to lecture me about email handling read “Reply-To” Munging Still Considered Harmful. Really. <https://woozle.org/~neale/papers/reply-to-still-harmful.html> Rob p.s. Liam's other footnotes: > [1] > https://wikimania2015.wikimedia.org/wiki/Submissions/User(s)_Talk(ing):_The… > > [2] > https://wikimania2015.wikimedia.org/wiki/File:User(s)_Talk(ing)_-_Wikimania… > [3] https://blog.wikimedia.org/2010/05/13/a-new-look-for-wikipedia/ > >

1 0

Which "Close" icon to use in UI interfaces?
by Andre Klapper 30 Jun '15

30 Jun '15

Could a Design Team member please answer the questions of a potential new contributor in "inconsistent close icon in MediaWiki interfaces" https://phabricator.wikimedia.org/T50067#526717 ? Thanks in advance!, andre -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/

1 0

Re: [Design] Big problem to solve: good WYSIWYG on WMF wikis
by Derk-Jan Hartman 17 Jun '15

17 Jun '15

https://lists.wikimedia.org/pipermail/foundation-l/2010-December/063225.html I just found back this post by David Gerard from 2010 and was struck by how dead-on the discussion and analysis was and how far we have actually come with VE 5 years later, even though we still did not pass the finish line just yet. Also interesting is some of the follow up to it, which points out that the usability of Templates is also a real problem in itself, not easily solvable with WYSIWYG, but probably just as important. I think VE is really close now to being usable in production, but I think that we are FAR from done on this front. Like was stated, templates are a real problem. A UI problem, and one that VE doesn't really solve. Citoid sort of does, but just for one small subset of templates. I think it is important to remember that VE is a framework. The piece that will open up other possibilities, but that we will need to still do a lot of work to find what those possibilities are, how they can make page and article authoring more usable etc... The post starts with a quote of Fred Bauder: "There has to be a vision though" So I'm asking: What is the vision for this next step ? - What ideas do people have with regard to usability and templates. - What examples of good editors can we find that also deal with templates/objects etc. - What are our unique challenges ? - What kind of research and development would be needed to deliver this ? I would love it if we could end up with a discussion and summary as we had back then. A guide for us towards solving this next problem within another 5 years. We and the WMF can probably not start on this tomorrow, but we can start thinking about it. DJ

4 3

Contributing to Wikimedia project
by Prastut Kumar 11 Jun '15

11 Jun '15

Dear Wikimedia Team, I am Prastut Kumar, a CS undergrad hailing from India and currently pursuing my Bachelors in Computer Science and engineering from VIT University, Chennai Campus. Wikipedia has always been a source of knowledge for people like me hailing from nations where information, valuable information cannot be found. "Knowledge shared is knowledge earned". Most of the time, while browsing through wiki, I have always thought of donating but couldn't due to economic reasons. But as I was going through GSOC voila! I found wikipedia there and also having separate design section! I wish to contribute to the design and aesthetics of the wikimedia project and gain essential skills to pursue my career as a web developer-cum-UI/UX expert. I know, I know GSOC has started. But there might be some opportunities which would still be open for a guy like me. I should make this very clear that I am solely contributing for the sake of contributing, not with any expectations attached to it. My question to you guys is, from where do I start contributing? How do I begin? Regards Prastut

6 5

Redesigning Help namespace on French WIkipedia
by Benoît Evellin 18 May '15

18 May '15

Hello design! *TL;DR* Help pages are just like encyclopedic pages on Wikipedia, but they have not the same goal: when you need an information to contribute, you need it quick. Since January, French Wikipedia community[6] has begun an important project: redesigning Help namespace. With this project, we want to create a specific design for help pages, with defined blocks to organize key points, big and readable titles, more friendly TOC, etc. The result is visible on two mockups[1][2] and a live demo[3]. This new design is quite ready, and we planned to deploy it on our common.css a few weeks ago in order to run some tests with new users. But some users has some rationale concerns about the deployment itself: we planed to create a new design by adding new CSS to the common.css file. This involves an important risk of conflict if there is an important skin update in the future. For us, next steps are: 1/ validate the choices we made for this new interface, 2/ create a separate skin (with an extension? An other solution?). We need you to help us on these two points. *Long version* On French Wikipedia - and I assume this is the same on other projects - help pages are just a an out-of-date mix of technical information without any organization. They are not easy to read! We also often have barbaric changes on Help namespace, by people who believe they are writing an article. With this design project, we plan to create more friendly help pages. We are working on two points: * the *content* (text, images) is rewritten in order to be shorter, more precise, and focused on what newbies ask all the time. We have separated basics from advances and expert knowledge. We are busting all not up-to-date information, pure technical stuff or jargon on basic help pages, encyclopedic style, etc. We are making a clear separation between technologies, with wikitext on one side and VE on the other[4]. * the *design* in order to have a presentation which is clear, more readable and efficient, and of course, user friendly to update. A page with the new design is now is divided into 4 big parts : * header * toc * contents * bottom We also have generic elements. First, the *header* presents (a lot of) information about the page: * a description which indicates the purpose of the page * a difficulty level (basics, advances, expert) in order to avoid surprises when a newbie reads the page * information about user status (when an account is needed, or autopatrolled status for example) * information about the concerned product (wikitext or VE) * links to relative contents, parent contents, etc. We have made a classification for help pages, based on action verbs (insert, create, discuss...). All this is included in one template. This is the only important template on an help page. The *TOC* is reduces to h2 and h3 titles, others are not displayed. By this, it is easier to read the TOC. When we modify an help page, we need to be more concise or create a specific page in order to detail a long point which requests h4 or h5 titles. The TOC displays h2 titles as a main title (bolder) and h3 as sub element (inline elements). By this, we emphasize key points and reduce the need of scrolling on the whole TOC when searching information. *Content* is composed of blocks, delimited by gray blocks. A block starts with a h2 title and stops when an other h2 title starts, with a visible white delimitation. The rule is now one information = one block (where I add a reference, how I add a reference, etc.). h3 titles are sub elements in their parent block. There are separated from the other elements by an horizontal gray line. An important padding makes the text column narrower, and easier to read. We are also working on best practices: add a tl;dr on the first section (called "à retenir" - not fo forget), short text on h3 sections, and more. When wikitext and VE are available to edit, we add on the *bottom* page a list of useful links: how to insert a link, a template, an image, etc. We also put generic informations about editing (no copyvios, reliable sources). We can imagine to have a form who takes feedback from readers (who says Article Feedback Tool?). In order to reduce efforts when reading the pages we have change some *generic elements*. The page has a max-width at 1,000 pixels. Text font has been enlarged by 0.1 em and titles redesigned to be like titles used on Flow (and quite more visible). Concerning colors, we have used the MediaWiki UI palette[5], especially the orange - which is a symbolic color for work in progress or constructions - and gray, already used on other products (Flow, MediaViewer). All these changes are inspired by other help pages on other big websites (Google docs, GMail, Facebook, Twitter, YouTube...): every time, content pages design and help pages design are different. You know you are on a place where you can have some help and some information. But not on Wikipedia. *And now?* Now this project is stopped, for the design part at least. We (the community) have some questions about the next steps. * Is there an official way to validate the choices we made for this new interface? We can run a test, but we don't have tools (or skills) for this. * in order to deploy this new design, we can create an extension. We have volunteers for this, with strong skills (some of them are already volunteers developers for MediaWiki). But is it the best way? Is there other ideas or solutions? We need you to help us on these two points. We will also be happy to have any feedback or advice about our project. :) On behalf of the Projet:Aide et Accueil[6], Benoît / Trizek [1] https://commons.wikimedia.org/wiki/File:Aide_Insérer_une_référence_Éditeur_… [2] https://commons.wikimedia.org/wiki/File:Aide_Homonymie_fr.wikipédia.png [3] On French Wikipedia, go to your preferences <https://fr.wikipedia.org/wiki/Spécial:Préférences>, *Gadgets* tab, and activate *MiseEnPageEspaceAide* gadget. Then go to Aide:Sommaire <https://fr.wikipedia.org/wiki/Aide:Sommaire> and browse help pages. [4] Example of page making the distinction between VE and wikitext, with a link to reach each technology : https://fr.wikipedia.org/w/index.php?title=Aide:Ins%C3%A9rer_une_r%C3%A9f%C… [5] https://commons.wikimedia.org/wiki/File:Mwuipalette.png [6] https://fr.wikipedia.org/wiki/Projet:Aide_et_accueil

5 5

Moving last modified to the bottom of the page on mobile
by Jon Robson 07 Apr '15

07 Apr '15

I'm still not convinced this is a good idea and this village pump post [1] seems to show its now just me (although there is also one of the opposite mindset). Please do consider this in the redesign which has now been promoted to beta. "Before in the mobile edition of Wikipedia, it showed at the top the hours or days since last revision and the user name. Now the username is not there. Bring it back and even consider it for the full desktop version. That is how we encourage people to update this site and not think some editorial board does it." [1] https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(proposals)#Bring_back…

14 26

Localizable tooltips, for html form fields - guidelines?
by Nick Wilson (Quiddity) 07 Apr '15

07 Apr '15

I've asked a few questions at https://phabricator.wikimedia.org/T95076 that someone here might be able to help with, namely: 1. What accessibility issues need to be considered, for using tooltips in form fields? (e.g. old browsers, screen-readers, accesskeys) 2. Do we have any mediawiki guidelines on what developers/extensions should use? (and should they be linked in the Living-Style-Guide <https://phabricator.wikimedia.org/tag/living-style-guide/> e.g. here <http://livingstyleguide.wmflabs.org/wiki/Inputs> or is that outside of it's remit?) 3. What is the best external documentation, and "best in class" examples? 4. Where do we currently store some examples? e.g. the title="Enter a short summary [Alt+Shift+b]" in enwiki's edit-summary field. 5. What pragmatic limits are there, on the formatting & length of tooltip content? (can we do split lines in basic HTML? How much harder is it to get clickable links in them? F108798 <https://phabricator.wikimedia.org/F108798>: this is very pretty, but the rendered HTML is gigantic, and it's still not clickable/copyable text.) 6. What other things should I/we be asking? Answers over there, please and thank you. :) -- Nick Wilson (Quiddity) Community Liaison Wikimedia Foundation

1 0

← Newer
1
...
13
14
15
16
17
18
19
...
61
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

Design