<quote name="Federico Leva (Nemo)" date="2014-02-15" time="22:52:31 +0100">
> And surely, before WMF/"MediaWiki" tell the world that no free fonts
> of good quality exist, there will be some document detailing exactly
> why and based on what arguments/data/research the numerous free
> alternatives were all rejected? Free fonts developers are an
> invaluable resource for serving Wikimedia projects' content in all
> languages, we shouldn't carelessly slap them in their face.
I just skimmed the entire thread again, and yes, this has been requested
a few times but no one from the WMF Design team has responded with that
analysis (or if would respond with an analysis). The first time it was
requested the person was told to ask the Design list, then the next
message CC'd the design list, but no response on that point.
I don't see much on https://www.mediawiki.org/wiki/Typography_refresh
nor it's talk page. Nor
https://www.mediawiki.org/wiki/Wikimedia_Foundation_Design/Typography
cc'ing the Design list :)
Greg
--
| Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |
This is really a UX question, not design per se.
https://gerrit.wikimedia.org/r/#/c/104926/ (an under-review change) adds
a warning if you choose a username that needs to be
reformatted/canonicalized. For example, "my username" is changed to "My
username".
It displays the warning, puts the new username ("My username") in the
box, then you have to retype your password (twice), then press enter to
confirm.
The main potential benefit, as I see it, is that if you don't like "My
username" (the reformatted version), you can choose a different username
entirely.
User experience feedback would be welcome; you can post on the change or
here.
Matt Flaschen
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
>
>