http://designatwikipedia.tumblr.com/post/62048718932/thoughts-on-humanizing…
"With humanizing articles, we have two objectives:
-Creating awareness about the editors and their interests on Wikipedia.
-Promoting connections within the community using shared interests."
The post shares some ideas and mockups and notes, "While the details are
being refined, comments on the general direction towards contributions
or alternate ideas would be super appreciated."
(By the way, after this email, I'm unsubscribing from the design list as
I prep for my sabbatical - more info at
http://lists.wikimedia.org/pipermail/wikitech-l/2013-August/071542.html
. If you need to talk about Wikimedia technical community stuff or
communication before January, please consult Quim Gil, qgil at wikimedia
dot org, or Guillaume Paumier, gpaumier at wikimedia dot org. Thanks!
Looking forward to coming back in January.)
--
Sumana Harihareswara
Engineering Community Manager
Wikimedia Foundation
[Please CC me on answers as I'm not subscribed.]
Hi,
I plan to enable a guided bug entry form on Wikimedia Bugzilla for
newbies, to make reporting issues slightly easier. It can be seen on
http://boogs.wmflabs.org/enter_bug.cgi?product=Wikimedia&format=guided
Login: test(a)test.wmflabs
Password: testtest
Is this utterly horrible and unusable, or can I deploy it on
bugzilla.wikimedia.org without making designers scream and ignore me for
the rest of my life? The CSS isn't great (at least it *is* CSS now,
sigh), but I needed to start somewhere.
Thanks in advance,
andre
PS: Quick'n'dirty CSS recommendations are also welcome.
--
Andre Klapper | Wikimedia Bugwrangler
http://blogs.gnome.org/aklapper/
Changed subject to reflect this change in topic. Also cc'ing design
mailing list.
In terms of external links to me I don't care about whether I'm leaving the
site or not. If I clicked on something and it wasn't what I expected that's
a badly labeled link. A link saying there is more information on the [white
house official website] and a link to the word [house] should be enough
information to tell which I'd external and which isn't.
I actually think the only place an icon next to a link really makes sense
is for downloads. Clicking something that downloads a PDF when I thought it
was a web page is a little confusing (on mobile at least).
That said if all the external links are in the external links / references
section wouldn't encouraging that organisation of links be better....?
Also I agree with Juliusz that we shouldn't force behaviour of where links
open. It should be up to the user if they want the same tab or new one and
it should be configurable within the browser preferences.
On 24 Oct 2013 16:07, "Juliusz Gonera" <jgonera(a)wikimedia.org> wrote:
> No, we should definitely not warn people, that's just weird ;) It's not
> like something bad is about to happen.
> I'm also not saying that users have the expectation that links point to
> local URLs, I'm only saying that it might be a useful piece of information
> to some.
>
>
> On 10/24/2013 02:48 PM, Jared Zimmerman wrote:
>
> Its definitely a less heavy handed way of doing the thing many
> (annoying) sites do when they warn you that you're leaving their site. I
> just wonder is the signal to noise it worth it. I don't know that modern
> web users have any expectations that link within a site always point to
> local site urls.
>
> *
> *
> *
> *
> *Jared Zimmerman * \\ Director of User Experience \\ Wikimedia
> Foundation
> M : +1 415 609 4043 | : @JaredZimmerman<https://twitter.com/JaredZimmerman>
>
>
>
>
Hello All,
It is my great pleasure to announce the promotion of Vibha Bamba to Senior
User Experience Designer.
Vibha is recognized for her leadership in mobile design at the foundation
as well as her recent efforts to “Humanize Wikipedia.” It should come as no
surprise that she is one of the pillars of our design group. Her efforts to
further Design internally at the Foundation as well as the Foundations
standing in the tech and non-profit Design community have helped us attract
new talent to the group as well as interest from community members wanting
to volunteer their time to improve the appearance and usability of the
projects.
Please join me in congratulating Vibha on this exciting news,
Jared Zimmerman
*
*
*
*
*Jared Zimmerman * \\ Director of User Experience \\ Wikimedia Foundation
M : +1 415 609 4043 | : @JaredZimmerman<https://twitter.com/JaredZimmerman>
I've merged Bartosz's patch (https://gerrit.wikimedia.org/r/#/c/82828/)
for rolling out the boxes to all forms, not just vforms.
He used the same colors as the vform styles. It seems to me that the
success and error boxes might be better with a little more color contrast.
You can test on Beta (http://en.wikipedia.beta.wmflabs.org/) by editing
your preferences (success), going to Special:UserLogin while logged in
(warning), and entering the wrong password for login (error).
Matt Flaschen
On 10/27/2013 03:37 PM, Steven Walling wrote:
> Many FOSS communities have dealt with the trade off between great-looking
> fonts and freedom by commissioning foundries to get their own free fonts.
> See also: Ubuntu, Android, and more. I've talked to the design team about
> this idea, including perhaps getting a foundry to donate a unique font
> stack in exchange for the publicity they'd get.
Do we really need our own, or are there already quality free fonts we
can list? Has the design team taken a good look at the existing free fonts?
My general position is that it is not a violation of our principles to
list a proprietary font in the stack. However, we should never
*distribute* such a font.
I would prefer that free fonts appear first, and that is more workable
if we can find good free fonts that suit our design needs. We should
also ensure that the interface does not look worse in the future than it
does today, when using free fonts.
Also, remember that font-matchers may substitute a free font when they
are given a proprietary font name.
Matt Flaschen
CCing design
On Mon, Oct 21, 2013 at 7:11 PM, Ryan Kaldari <rkaldari(a)wikimedia.org> wrote:
> Recently on mobile we switched our iconography used to represent a user from
> being a simplified head and shoulders to being a square smiley face.
> Unfortunately, the square smiley face is already being used to represent the
> thank action (via the Thanks extension). You can see an example of these two
> UI elements being used on the same page in this design mock-up for the
> mobile media viewer:
> https://commons.wikimedia.org/wiki/File:Media-viewer-tools-mobile-design-pa…
>
> As you can see, it's a bit confusing having 2 square smiley faces in the
> same interface representing separate things (not to mention the square
> frowny face for the flag action).
>
> I would suggest that we change one or the other. Since the thank iconography
> has already been through much debate and revision (originally being a red
> heart, then a green heart, then a smiley face), I would favor changing the
> user iconography back to a head and shoulders. Thoughts?
>
> Ryan Kaldari
On 10/24/2013 08:27 PM, Steven Walling wrote:
> Thanks for doing this Jon.
>
> When I used the Vector version, at first I got an all black screen, which
> made me think it was broken. I guess that was just a CSS rule to click and
> delete? :)
Yes.
> Yeah, if we don't have a bug about settling on one overlay style, we
> should. This is pretty bad. Maybe the work being done to split out
> ve.ui/oo.js/whatever we're calling it might help us settle on a standard?
It's part of https://bugzilla.wikimedia.org/show_bug.cgi?id=55534
>> * .guider_button
>>
>
> Extension:GuidedTour. Matt will explain more I'm sure.
Right. As noted, it's not actually being used.
To complicate it further, I think the UX team actually now wants to go
in a totally different direction with no blue buttons at all
(https://www.mediawiki.org/wiki/File:WMF_DESIGN_Password_Reset.png).
So we should try to finalize that if possible. That might avoid people
having to go back and change their HTML twice (once to use mw-ui,
another to e.g. add another layer).
In some cases CSS can be changed alone, but sometimes they have to be
changed in tandem, which is more code to touch.
CCing the design list.
Matt
