On Mon, Feb 17, 2014 at 12:38 PM, Steven Walling
<steven.walling(a)gmail.com>wrote:
> Sacrificing the readability and beauty of content for
> most users because there is no universally perfect solution is the kind of
> hard-line approach that limits the reach of FOSS, and ultimately undermines
> our goal of making something the entire world can use and enjoy.
I need to challenge the assertion that this is about most users. Here's my
understanding of the status quo: for prose, we currently specify the
neutral and non-descript "sans-serif". This results in the following fonts
on the default install on these platforms if I've done my homework
correctly:
* MS Windows: Arial(?)
* Mac: Helvetica
* Ubuntu/Firefox: DejaVu Sans (presumably other Linux variants are similar)
* Ubuntu/Chrome: Liberation Sans
* Android: Roboto
* iOS: Helvetica(?)
Note that the differences between Firefox and Chrome on Linux seem to stem
from Firefox using the OS standard font resolution mechanism, and Chrome
having a built-in heuristic that seems to be very heavily biased toward
Liberation Sans.
Under the new "Helvetica Neue", Helvetica, Arial, sans-serif font stack, we
get:
* MS Windows: Arial(?)
* Mac: Helvetica Neue
* Ubuntu/Firefox: Nimbus Sans L (Helvetica substitute)
* Ubuntu/Chrome: Liberation Sans (Helvetica and Arial substitute)
* Android: Roboto
* iOS: Helvetica Neue
This doesn't seem like a satisfying leap forward, given the level of
disruption.
* By our numbers[1], a plurality of our users are using MS Windows still
(and probably a majority of those using the desktop site). They got Arial
before, and they get Arial now.[2] The only way they improve their
experience is to buy Helvetica Neue or buy a product that includes
Helvetica Neue. Moreover, it's quite possible that MS Windows users will
get a crappy experience with Helvetica if they have an old Type 1 version
of it installed on their system.[3]
* It looks like this causes shift from Helvetica and Helvetica Neue on Mac
and iOS, which would seem to be to be pretty subtle. How big is the
difference on the site? I don't have access to a Mac at home, so I can't
see the difference myself, but the available screenshots don't present a
noticeable difference to me.
* If cross-platform consistency is the goal, I think this misses the mark.
In particular, Android would still be using Roboto, which has quite
different metrics than the Helvetica/Arial set of fonts. Additionally, we
still end up with a difference between our two most popular Linux browsers,
which while not as large as before, still seems unnecessary.
Here is what seems to be a reasonably well-researched article where the
author has clearly put a lot of thought into the cross-platform experience,
with the added bonus that it proposes use of free (libre) fonts:
http://www.grputland.com/2013/11/multiplatform-helvetica-like-font-stack.ht…
tl;dr: His stack still lists HelveticaNeue as the first font, but proposes
Arimo as a web font which may well look better on MS Windows. Arimo ships
with ChromeOS.
I believe it is worth more research on replacements for free and better
alternatives to Arial, because it would seem to me that it's not hard to do
better. While it's unlikely that most MS Windows users will install Arimo,
it sends a way better message if we can say "to make your Wikipedia reading
experience better, download and install the free font Arimo" than it does
to say "to make your Wikipedia experience better, please purchase Helvetica
Neue for the low low price of $29.95". Furthermore, it may be worth it to
try out the web font mechanism, and we might even be able to talk Mozilla
and/or Google into shipping a free font or two with the browser so as to
get some real install penetration with these fonts.
In general, it feels as though this iteration is centered around only
making the experience for Apple products better, while trying not to break
the experience on other platforms, which feels like a low bar. It's not
entirely clear how much hands-on effort the User Experience team has put
into Windows, Android tablets, ChromeOS, or other Linux desktops, or what
the team's goals are for those platforms. The fact that much of the
rationale for the new design centers around greater use of Helvetica Neue
specifically (which is not free, and is only available to a minority of our
users) is annoying to me, and that seems to be where a lot of the
frustration from others comes from as well.
Rob
[1]
http://stats.wikimedia.org/wikimedia/squids/SquidReportOperatingSystems.htm
[2] I don't have a modern system with Windows 7 or 8 on it, so I don't
know if they've switched to Segoe as the default. If so, we may be making
an unintentional downgrade to Arial with our new choice.
[3]
http://stackoverflow.com/questions/15011653/internet-explorer-automatically…
I forgot to update the recipients, this was meant for design@. Sorry for
the duplicate.
Tomasz Finc, 09/10/2013 00:57:
> CC'ing team practices list for broad awareness
>
> And for those that are looking for other teams process/definition there
> is a nifty category that has all of it
>
> https://www.mediawiki.org/wiki/Category:Wikimedia_Foundation_teams_internals
Bump. I love seeing that category growing. :)
It seems that this discussion on documentation (process, collaboration,
communication etc.)... was not documented, despite being on/off for
months now. I've dropped something on wiki:
<https://www.mediawiki.org/wiki/Thread:Talk:Design/Design_process_and_docume…>.
Nemo
>
>
> On Tue, Oct 8, 2013 at 3:55 PM, Jared Zimmerman
> <jared.zimmerman(a)wikimedia.org <mailto:jared.zimmerman@wikimedia.org>>
> wrote:
>
> *Thomas*, looks great, I'll start
> https://www.mediawiki.org/wiki/Design/Team this week.
>
> *Arthur*, Yes, please work this out with your Primary designer
> specifically. In your case Kaity. The reason we're attempting to
> have all designers on the same schedule for Focus & Explore is so
> they can work and brainstorm together if they prefer.
>
> *
> *
> *
> *
> *Jared Zimmerman *\\Director of User Experience \\Wikimedia Foundation
> M : +1 415 609 4043 | : @JaredZimmerman
> <https://twitter.com/JaredZimmerman>
>
>
>
> On Tue, Oct 8, 2013 at 3:50 PM, Jared Zimmerman
> <jared.zimmerman(a)wikimedia.org
> <mailto:jared.zimmerman@wikimedia.org>> wrote:
>
> Yes, *Steven*, do you have a specific place you'd recommend it
> go on office wiki, I'd be happy to post it there. As far as the
> audience, the design group has many "clients" within the
> organization and I didn't want to accidentally omit any. As with
> any other thread that isn't relevant to you Gmail's mute feature
> <https://support.google.com/mail/answer/47787?hl=en> is great.
>
> Correct, *Arthur* while gmail excels in muting, it fails in
> search and replacing. Flare = secondary
>
> *
> *
> *
> *
> *Jared Zimmerman *\\Director of User Experience \\Wikimedia
> Foundation
> M : +1 415 609 4043 <tel:%2B1%C2%A0415%20609%204043> | :
> @JaredZimmerman <https://twitter.com/JaredZimmerman>
>
>
>
> On Tue, Oct 8, 2013 at 3:30 PM, Steven Walling
> <swalling(a)wikimedia.org <mailto:swalling@wikimedia.org>> wrote:
>
> Can we put this in a document somewhere, like Office Wiki,
> instead of via wmfall email?
>
> I am not sure this email was relevant to all 150 staff
> including HR, finance, and others who almost never work with
> designers.
>
>
> On Tue, Oct 8, 2013 at 3:14 PM, Jared Zimmerman
> <jared.zimmerman(a)wikimedia.org
> <mailto:jared.zimmerman@wikimedia.org>> wrote:
>
> Meetings are the mind killer. But collaboration can set
> us free.
>
>
> I've been thinking a lot lately about how Design works
> in tech, what works well and what is broken. How Design
> can use Agile methodologies to its advantage, and how
> the proliferation of meetings in agile can be a serious
> detriment to the creative process.
>
>
> I'm rolling out a few changes to the way Design will
> work with the teams and functional groups at the foundation.
>
>
>
> New Roles : Primaries & Secondaries
>
> Each focus area will be assigned a Primary and a
> Secondary from Design, these are the designers who will
> be your primary contact for a project or feature area.
>
>
> Primary— Invite the Primary to your standups and all
> meetings where design should have a presence. They will
> attempt to attend as many meetings that are relevant to
> design as possible. Invite Primaries to any project
> specific reviews and planning meetings, they will speak
> for design in these meeting. If they don't know the
> answer, they will find out. Primaries are responsible
> for working with PMs to define realistic schedules based
> on their own availability and that of the designers that
> will support them.
>
>
> Secondary— Secondaries support Primaries when it comes
> to making the work happen. While each group will have
> one official Flare, they may not be the only design
> support on a given feature. You should invite them to
> meetings where entire engineering teams are present.
> When a meeting needs to happen ASAP look to the Primary
> first, if they are not available the Secondary can
> represent design in their absence.
>
>
>
> Focus, Explore, and Collaborate
>
> Sometime designer work best when they are juggling 10
> projects at once, sometimes they work best when they can
> focus on a single task with no interruptions.
>
>
> Going forward the designers will block off one day of
> their calendar every week for Focus, and one for
> Explore. The remaining days will be for scheduled work
> and collaboration.
>
>
> Ideally we would have every designer have the same
> schedule for Explore, Focus, and Collaborate but this
> might not be possible due to individual and project team
> schedules. Designers will block out Focus and Explore on
> their calendars so externally it will be obvious which
> days are reserved.
>
>
> Focus
>
> In order to give their full attention to a design
> problem without having to context switch between
> meetings, Focus is a day without structured meetings.
> During Focus, designer may be in the office or they may
> be working from home, or a park, or a cafe, or in the
> office. Please do not schedule meetings with designers
> during Focus, or expect them to attend standups or other
> recurring meetings on this day.
>
>
> Explore
>
> During Explore designers can explore areas that they
> aren't assigned to, focus on projects that are important
> to them, and devote time researching new project that
> could shape the future of the Foundation and its
> projects. Please do not schedule meetings with designers
> during Explore, or expect them to attend standups or
> other recurring meetings on this day. Monthly the design
> team will host a 1 hour brown bag "Explore Wikimedia
> Design" that is open to the Foundation to attend, to
> showcase what designers have spent their Explore days
> focusing on as well as increase visibility for other
> projects that they are working on.
>
>
> Collaborate
>
> Mostly the same fun times you're used to, schedule
> meetings, write on whiteboards, have working sessions,
> etc. desk time doing design work.
>
>
> What does this mean to me as…
>
>
> an Engineer? You should still feel free to bring
> designers into your discussions and brainstorms,
> approach them with your projects, and questions. In lieu
> of scheduling meetings with designers on Explore days,
> simply walk over (or ping on IM) and see if they are
> available to talk.
>
>
> a Product Manager? When you're planning small meetings
> and projects make sure to invite your Spark, when
> planning larger meetings (quarterly kickoffs, roadmap
> planning) invite both your Primary and Flare,
> communicate project needs and timelines directly with
> your Spark.
>
>
> Everyone else? Come to Explore Wikimedia Design brownbag
> to get inspired, and understand what the Design team is
> working on.
>
>
>
> Feature Areas and Project
>
>
> Key:
>
> Design area
>
> Primary
>
> Secondary
>
>
> Analytics tools
>
> Pau
>
> Kaity
>
>
> Core Features
>
> May
>
> Brandon
>
>
> Growth
>
> Pau
>
> Vibha
>
>
> Language Eng.
>
> Pau
>
> Kaity
>
>
> Mobile
>
> Kaity
>
> Vibha
>
>
> Multimedia
>
> Vibha
>
> Pau
>
>
> Platform
>
> May
>
> Kaity
>
>
> Visual Editor
>
> Vibha
>
> Kaity
>
>
> Global Profiles
>
> Brandon
>
> Vibha
>
>
> Affiliations/Groups/Campaigns
>
> Brandon
>
> Kaity
>
>
>
>
> Questions & Answers
>
> Q: What if my team or project isn't mentioned?
>
> A: Try as I might I can't always be aware of every
> project that’s going at all times, if I've missed your
> project or feature please get in touch with me and I
> will make sure I do my best to make sure we provide
> design coverage for you.
>
>
>
> Q: How will you handle new designers being added to the
> team?
>
> A:As you can see above, even with the Design team
> growing many members are doing double duty as both
> Primary and Secondary on for multiple projects, as new
> designers are added to the team we will load balance as
> needed. Mostly likely new designers will join a project
> as a Secondary to get up to speed before being assigned
> to a new project or iteration of an existing one.
>
>
>
> Q: Does this mean I'll have the same designer(s) for the
> length of a projects?
>
> A: This is the goal, especially for the Spark, however
> as projects and resources change the Secondary assigned
> to a project may change if they are needed as a Primary
> on another Project, and vice versa.
>
>
>
> Q: What is the analogy between agile terms and Primaries
> and flares (for instance, is a Primary a scrummaster? a
> design tech lead? and a flare an engineer?)
>
> A: I had to do a lot of thinking about those roles and
> how they fit with design, if you mustdraw correlations
> between this framework and agile, the Primary is more
> like the Product Owner, In most teams both of those
> agile roles are already well covered and I'm not
> attempting to replace them. The Primary may also not be
> the one doing the most work on a feature area, but they
> are the main point of contact for other stakeholders.
>
>
>
> Q: Will Primaries sit with their teams?
>
> A: Maybe, this is up to the individual designers, I'm
> not going to mandate it, since each designer is a
> Primary for multiple teams (for now) it might end up
> with a lot of moving around day-to-day, also the
> designers like to sit next to each other so they can
> bounce ideas off each other.
>
>
>
> Q: What is the schedule?
>
> A: Designers have blocked out on their calendars
> Wednesday for Focus, and Friday for Explore, starting
> the week of 10/14
>
>
>
> Q: When is Explore Wikimedia Design?
>
> A: Monthly, dates TBD.
>
>
>
> Q: How will explore projects be built?
>
> A: In the case of Brandon and Pau, they may build their
> Explore projects themselves, in the case of the other
> designers, the monthly Explore Wikimedia Design brownbag
> share out will be a venue for developers to see things
> they are interested in building during their own
> time/20% time.
>
>
> All of the Explore work will be on-wiki both for
> feedback and for the community to be inspired by, We can
> work with Quim/Sumana to see if there is
> interest/availability in the community to build some of
> the explore features as well.
>
>
>
> Q: Is there a possible consensus/collaboration-driven
> way of handling designer/team assignments in the future?
>
> A: I can see this happening for future projects, but
> right now my focus is good coverage on projects that are
> already underway. I'm certainly open to individual
> designer mutually agreeing to swap roles for projects as
> well.
>
> Q: Will weekly design critiques go back to being design
> only? How will other teams hear about the decisions and
> discussion?
>
> A: Yes,Design reviews will be designers only going
> forward, they way they were originally, we've tended to
> post the feedback/notes, on a per project spaces, but we
> can also have a more general place to post these notes
> as well.
>
>
>
> Q: What if the days for collaborates for a team don't
> leave this flexibility in the schedule (no single match
> point)?
>
> A: This new schedule may alter the team velocity,
> however I think it will also increase quality and team
> happiness. Therefore it is in line with the tenant of
> "Do less, better
> <http://www.markramseymedia.com/2013/09/do-less-better/>" I'm
> ok with this. Are the other teams?
>
>
>
> Q: How do we determine how well this arrangement is
> working? or "What does success look like?"
>
> A: At its simplest level, success is a happier design
> team, where members feel like they can think further out
> in the future, and develop a creative vision with me for
> the future of our projects, they don't feel that now
> because much of our work is reactive to all the things
> that feel like they need to be done right now.
>
>
> The other major factors for success to me are a backlog
> full of designs that are interesting to foundation and
> community engineers. A clearer vision of the design
> roadmap. Elevation of the WMF as a place where great
> designer and designer flourish in an open (source)
> environment. A clear direction for where we want to be
> with design for the projects in 6 mo, a year, 3 years.
>
>
>
> Q: What does failure look like?
>
> A: Designer feel like they have too much work and spend
> explore doing assigned projects. Designers can't
> time-box themselves to focus on projects with the right
> balance. A lot of time is spent on Explore designs and
> no one in the community or foundation wants to build
> them. Explore projects don't feel like they form a
> cohesive vision for the future of design at WMF.
>
>
>
> Q: What is the role of Primary & Secondaries when
> interacting with the community?
>
> A: Both roles will be responsible for getting designs
> on-wiki, and responding to user and team comments
> on-wiki this is the current process and I believe it
> works well.
>
>
> Both roles will be in contact with their PM & CL to have
> the CL to do community research, and outreach. I don't
> see this part of the process changing much, I'm not
> aware of any issues with the current state of things in
> this regard, let me know if there are issues I'm unaware
> of.
>
> Any questions don't hesitate to contact me.
>
>
> *
> *
> *
> *
> *Jared Zimmerman * \\ Director of User Experience \\
> Wikimedia Foundation
> M : +1 415 609 4043 <tel:%2B1%C2%A0415%20609%204043> | :
> @JaredZimmerman <https://twitter.com/JaredZimmerman>
>
>
> _______________________________________________
> Wmfall mailing list
> Wmfall(a)lists.wikimedia.org
> <mailto:Wmfall@lists.wikimedia.org>
> https://lists.wikimedia.org/mailman/listinfo/wmfall
>
>
>
>
> --
> Steven Walling,
> Product Manager
> https://wikimediafoundation.org/
>
> _______________________________________________
> Wmfall mailing list
> Wmfall(a)lists.wikimedia.org <mailto:Wmfall@lists.wikimedia.org>
> https://lists.wikimedia.org/mailman/listinfo/wmfall
>
>
>
>
> _______________________________________________
> Wmfall mailing list
> Wmfall(a)lists.wikimedia.org <mailto:Wmfall@lists.wikimedia.org>
> https://lists.wikimedia.org/mailman/listinfo/wmfall
>
>
>
>
> _______________________________________________
> teampractices mailing list
> teampractices(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/teampractices
>
Hie,
I am a newbie in wikimedia community and I was working on this bug to start
of.
https://bugzilla.wikimedia.org/show_bug.cgi?id=11269
It required two parts to be done and I was able to fix the first part
(please see comments on bug). However, while working on the second part
which requires a set of page numbers to be generated while listing the
pagination, I was able to do most of it except how to get the upper limit
of page numbers.
I figured, this will require a query on the table to get total number of
results in it. However the QueryPage::reallyDoQuery() function takes input
the limit and the offset value only. I tried to do something like
"SQL_CALC_FOUND_ROWS" but was not able to figure out how to implement this.
Please give some suggestions.
Thanks.
I have uploaded a new version of the Winter prototype. This is a pretty significant update in terms of functionality and bugfixes, not the least of which include full support for history, contributions, and edit modes (though they do not save).
As always, you can play with it at http://unicorn.wmflabs.org/winter/
And provide feedback at: https://www.mediawiki.org/wiki/Talk:Winter
(Please note that very soon I will Flow-Enable the Winter talk page).
Here’s your changelog:
=== New Features ===
* Added version identifier in sidebar.
* Significantly upgraded the prototype chassis:
** Added functionality to pass Page names to the url with ?page=$PAGENAME
*** This allows the prototype to open new tabs and such.
*** Other actions also follow suit (edit=, history=, contribs=)
** Added "History" functionality
** Added "Contributions" functionality
** Added "Edit" functionality
*** Edit-mode controls are placeholders and not implemented. Also incomplete.
*** Always loads source editor
*** Links to article/user and discussion both appear here.
*** Section edits also work
*** DOES NOT SAVE.
*** Changed "Edit Source" to "Edit Visually" in edit button menus because we're not faking up the visual editor (At this time)
* Search box now works and does basic type-ahead lookups.
** Not entirely fully functional (e.g., does not auto-select)
** Some issues with clicking out of the search area not defaulting back to the page title
** No full search functionality (yet)
* Additional sidebar toggles:
** Quiet Mode: (default)
*** This applies several visual changes to the button ribbon (including border removal)
*** Also slots the button ribbon right below the page title
** Thin Mode: (default)
*** This reduces several borders to 1 pixel instead of 2.
* Sidebar settings now are remembered between pages.
** Cookie clears with "clear saved data"
* Personal bar now collapses when page-context tools pop into the header.
** Animation could use some work.
* Changed avatar icon
* Added link to notifications from user pulldown menu
* Added small color highlight to internal tabs/buttons to indicate location
* Attached several "This is not implemented" modal dialogs to various actions.
=== Bugfixes ===
* Clicking on internal hashlinks (like from the TOC) now target correctly given the fixed header.
** Also smooth scroll animation.
* Page now scrolls to top when new page is loaded
* Toolbox sections now open and close correctly
* Found broken css rule that was applying a ginormous font size to all <a> tags.
* Applied a max-height to the header table of contents and gave it scrollbars when the size of the TOC is larger than its content.
* Page co-ordinates now go to the correct place
* Language links now list the name of the language, not the name of the article
** This was a pain. This data needs to be in the API call.
* "Discussion" link now becomes "article" link on discussion pages.
* Redlinks now appear red.
== Known Issues ==
=== Current ===
* Contributions views:
** Timestamps don't sort right
** Comment fields are not correctly parsed from wikitext to html
** Size changes are not correctly reflected
* System does not always handle 404 loads correctly (can fail silently, requiring a reload)
* Internal hash URLs don't scroll correctly when loaded from external sources (this is a problem with the prototype specifically and will not appear in the production version)
* Keyboard accellerators do not work. This is a problem of the prototype specifically and will not happen with the production version.
* Loading from JSON breaks the nice little "section hover" stuff.
* Categories are not displayed correctly, if at all.
* Wrong link colors
=== Fixed/Addressed ===
==== In Winter 0.4 ====
* Some buttons don't go away when they should
* Redlinks do not work
* Clicking on a section title in the table of contents forwards to the correct section, but the section header is covered by the search bar
* Button size off-set issue appearing in Firefox (thanks, Sven!)
---
Brandon Harris, Senior Designer, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
Welcome Yufei.
On Mon, Feb 10, 2014 at 12:08 PM, Heather McAndrew
<hmcandrew(a)wikimedia.org>wrote:
> Welcome Yufei!!
>
> Heather
>
> *Heather McAndrew*
> *Recruiter*
> hmcandrew(a)wikimedia.org
> www.linkedin.com/in/recruitervolunteerheather/
> *415-839-6885 <http://www.linkedin.com/in/recruitervolunteerheather/> ext.
> 6829*
>
>
> Follow us on Twitter @wikimediaatwork
> We welcome you to contribute to Wikipedia: http://bit.ly/Imnhhttp
> Developers-Join us on IRC: http://bit.ly/VC07xq
> Become a Product Advisor: http://bit.ly/R1obwD
>
>
> On Mon, Feb 10, 2014 at 12:05 PM, Jared Zimmerman <
> jared.zimmerman(a)wikimedia.org> wrote:
>
>> Hello All,
>>
>> I’m very happy to announce the addition of YuFei Liu as Visual Design
>> Intern to the UX Design team. YuFei will help the design, communications,
>> and legal teams by leveraging all the strengths of our existing branding,
>> identifying and organizing it into a cohesive package that can be reused in
>> consistent ways.
>>
>> Yufei (you fey) is a visual designer with a focus on building holistic
>> brands beyond simple logos and marks. She understands the complexity of
>> working in situations where there are immutable elements that must be taken
>> into account and worked with, rather than worked around.
>>
>> She is a recent graduate of Academy of Art University with an MFA in
>> Graphic Design after completing a BFA in Interior Design at Beijing City
>> University in China.
>>
>> When YuFei isn’t helping us wrangle the herd of cats that is the current
>> state of our branding she is traveling, hiking, reading and taking photos.
>>
>> YuFei will be working in conjunction with the Communication and UX team
>> to refine branding for the touchpoints in web and print collateral. She’s
>> located in San Francisco and will be here in the office sitting on the
>> North side of the 3rd floor next to Vibha, opposite Steven. Come say hello
>> or 你好!
>>
>>
>>
>>
>> some links:
>>
>> http://www.yufeiliustudio.com
>>
>> *Jared Zimmerman * \\ Director of User Experience \\ Wikimedia
>> Foundation
>> M : +1 415 609 4043 | : @JaredZimmerman<https://twitter.com/JaredZimmerman>
>>
>>
>> _______________________________________________
>> Wmfall mailing list
>> Wmfall(a)lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wmfall
>>
>>
>
> _______________________________________________
> Wmfall mailing list
> Wmfall(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wmfall
>
>
--
Kenan Wang
Product Manager, Mobile
Wikimedia Foundation
Hello All,
I’m very happy to announce the addition of YuFei Liu as Visual Design
Intern to the UX Design team. YuFei will help the design, communications,
and legal teams by leveraging all the strengths of our existing branding,
identifying and organizing it into a cohesive package that can be reused in
consistent ways.
Yufei (you fey) is a visual designer with a focus on building holistic
brands beyond simple logos and marks. She understands the complexity of
working in situations where there are immutable elements that must be taken
into account and worked with, rather than worked around.
She is a recent graduate of Academy of Art University with an MFA in
Graphic Design after completing a BFA in Interior Design at Beijing City
University in China.
When YuFei isn’t helping us wrangle the herd of cats that is the current
state of our branding she is traveling, hiking, reading and taking photos.
YuFei will be working in conjunction with the Communication and UX team to
refine branding for the touchpoints in web and print collateral. She’s
located in San Francisco and will be here in the office sitting on the
North side of the 3rd floor next to Vibha, opposite Steven. Come say hello
or 你好!
some links:
http://www.yufeiliustudio.com
*Jared Zimmerman * \\ Director of User Experience \\ Wikimedia Foundation
M : +1 415 609 4043 | : @JaredZimmerman<https://twitter.com/JaredZimmerman>
cc design. the colours were chosen based on colour blindness and various
other factors . I'm off on vacation but maybe Vibha has a summary of the
work that her and Munaf did...
On 8 Feb 2014 10:52, "Amir E. Aharoni" <amir.aharoni(a)mail.huji.ac.il> wrote:
> Hi,
>
> A Hebrew Wikipedia user complained that the mobile diff colors changed to
> dark green and dark pink, which she finds very inconvenient.
>
> What would be the right way to report that? Bugzilla? Some talk page about
> Mobile Feedback? [[mw:Talk:Mobile_design]] is empty, but it can be started.
>
> I presume that some serious design work went into that, and I don't have a
> strong opinion of my own, but hey - I'm quite pleasantly surprised that
> somebody cares about mobile diff colors, so I guess that it should be
> considered.
>
> --
> Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
> http://aharoni.wordpress.com
> “We're living in pieces,
> I want to live in peace.” – T. Moore
>
> _______________________________________________
> Mobile-l mailing list
> Mobile-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>
>
Hallo.
DYK: The first commit in the MediaWiki source repo is the change from
"Older versions" to "Page history".[1]
Does anybody think that calling the "history" tab "history" is really very
good?
Version "history" is a rather technical term that not all people who aren't
developers necessarily. understand without explanation. This becomes even
more confusing on a site like Wikipedia, many of whose pages deal with
History. This is anecdotal, but I saw people clicking the "History" tab in
the English Wikipedia and getting confused, because they expected to see
stuff about generals, monarchs and discoveries. Calling it "View history"
is not much better.
"Older versions" or "previous versions" or something along these lines
describes the essence of the link more precisely and clearly.
My home wiki, the Hebrew Wikipedia, calls the history tab "Previous
versions", even though in MessagesHe.php it's translated as "History". I
went to all the other Wikipedias that have over 50,000 articles and found
interesting results. Wikipedias in 7 languages don't call this tab
"history" or "view history", but rather:
German: Version history
Italian: Chronology
Polish: History and authors
Indonesian: Previous versions
Hebrew: Previous versions
Croatian: Show older changes
Latvian: Chronology
It's not a majority, but it does show some interesting variety, which must
not be ignored.
So I'm asking the experienced design people and anybody else who has an
opinion: Now that we are talking so much about major design changes
(Winter, etc.), can we consider changing this as well?
[1]
http://git.wikimedia.org/commitdiff/mediawiki%2Fcore/bdf01f1062405e1f2b46a9…
--
Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
http://aharoni.wordpress.com
“We're living in pieces,
I want to live in peace.” – T. Moore
Hello All,
I'm very happy to announce the addition of Preteek Saxena as UX Prototyping
contractor to the UX Design team. Prateek will help the design team build
high fidelity mockups that allow us to do moderated and unmoderated user
testing with systems that test concepts outside the roadmaps of other
groups for early validation. Prateek will also aid in transitioning Explore
(20%) time experiments into code launchable as Beta Features.
Prateek is a developer with an eye for design. He has worked with
foundation developers on various projects in the past including the mobile
team. He has developed primarily for the web using frameworks like Ruby on
Rails in the back end and d3.js and jQuery on the front end. He has also
worked on design for the web, mobile and print.
When Prateek isn't making beautiful functional prototypes he can be found
working on game prototypes http://xvii.in/ & http://vertigo.clay.io/ and
making music with friends https://soundcloud.com/bowl-of-petunias
Prateek will be working with my team and product managers to bring static
design concepts to life. He will initially be focused on Navigation Popups
and Fixed Header Beta Features, but will certainly branch out to work with
us on other projects. He is located in Mumbai, so you'll mostly see him on
IRC or via email.
some links:
http://prtksxna.com/work/https://github.com/prtksxnahttp://xvii.in/http://vertigo.clay.io/https://soundcloud.com/bowl-of-petunias
*Jared Zimmerman * \\ Director of User Experience \\ Wikimedia Foundation
M : +1 415 609 4043 | : @JaredZimmerman<https://twitter.com/JaredZimmerman>