There is a conversation going on here about consolidating constructive
and progressive buttons: https://phabricator.wikimedia.org/T110555
I want to find out if any of you have used these buttons in your
interface and have done any testing with your users to see if they
understand the difference between the two. Also, if you have used it
in other ways that has been helpful to your users, chime in!
Progressive (blue) conveys to the user that they are starting or
continuing a multi-step process.
Constructive (green) conveys to the user they are completing a single
or multi-step process. In most case Constructive color shows the user
what will happen. In others it is feedback that the action has
completed. For example, thanking a user, adding a page to a watch
list.
--
Related discussion about button consolidation:
https://phabricator.wikimedia.org/T110565
mm
Hi folks,
@cscott <https://phabricator.wikimedia.org/p/cscott/> pointed out that in
our next RfC meeting on IRC (happening later today) it would be great to
have some design/UX input.
The specific task we're talking through is T90914: Provide semantic
wiki-configurable styles for media display
<https://phabricator.wikimedia.org/T90914>
The IRC meeting we're talking about is E68: RFC Meeting on
#wikimedia-office IRC channel (2015-09-30 UTC)
<https://phabricator.wikimedia.org/E68>(today at 2pm PDT). We already
doubt that any final decisions will be made at this, but getting your input
on this today should be extremely helpful for moving things along.
>From a Phab perspective, I would like to generally tag RfCs that need
design input, but I don't know what the best way of doing that. What tag
should we use to make you aware of RfCs that should have design/UX input?
If there isn't a tag that's a good fit, could we figure out a tag we should
create for this purpose?
Rob
---------- Forwarded message ----------
From: cscott <no-reply(a)phabricator.wikimedia.org>
Date: Wed, Sep 30, 2015 at 8:16 AM
Subject: [Calendar] E68: RFC Meeting on #wikimedia-office IRC channel
(2015-09-30 UTC)
To: robla(a)wikimedia.org
cscott added a subscriber: cscott.
cscott added a comment.
@RobLa-WMF <https://phabricator.wikimedia.org/p/RobLa-WMF/>: I'd like to
get some designers' input on T90914
<https://phabricator.wikimedia.org/T90914>, I don't know if they're in the
habit of attending rfc meetings in general. So I'd prefer to have good
advance notice, and publicize the meeting via email involving the design
team, etc.
*EVENT DESCRIPTION*
Location: #wikimedia-office IRC channel
Time: 2015-09-30, Wednesday 21:00 UTC
* {T112553}
* @GWicke is eager to move this one forward, and doesn't //seem// too
controversial
* {T90914}
* We hope to give @cscott some time to move this one forward, but we may
not have time to make much progress on this one.
We've also tentatively set up {E74} for a few hours after this meeting.
*EVENT DETAIL*
https://phabricator.wikimedia.org/E68
*EMAIL PREFERENCES*
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
*To: *RobLa-WMF, cscott, ArchCom
*Cc: *cscott, tstarling, GWicke, devunt, daniel, Jay8g, bd808, Legoktm
Let's revisit the basic way that Mediawiki lays out media and content.
It has worked well enough for twenty years, but perhaps we can do
better.
In particular, I would like to be able to (a) make Wikimedia projects
looks Really Beautiful (b) on a variety of different devices and
formats.
Mobile and print are the forerunners here: in both cases we'd like
more flexibility to lay out infoboxes, media, tables, and content in
not-strictly-linear ways:
1) We'd like to be able to tag lead images, and use them more
generally (backgrounds for page titles, previews, etc)
2) Infoboxes, references, footnotes, etc want to be untethered from
their source location in the content and moved around -- for example,
to sidebars or popups on mobile; to the footer or dedicated pages in
print.
3) We would like to be able to crop and scale images better, but need
focal point information or a box around critical regions of the image.
(If the article is about the sun, and the photo is of a sunny day,
cropping the sun out would be bad. Other images have critical
features at the edges of the image we don't want to lose.) We
currently have a single option "thumb", and a single user-specified
scaling factor, meant for accessibility --- but an accessible size
will differ on different devices, and the scaling factor doesn't apply
to all images, only to those using "thumb".
4) We need more semantic information about images in order to make
better layouts: in print, is this a "wide" image appropriate for
spanning across multiple columns, or a "feature" image appropriate for
having a page to itself? Is this a meaningful parallel grouping of
images (ie, before and after) which shouldn't be broken up (but could
be arranged either horizontally or vertically, or perhaps with a
slider)? Should this image be laid out inline (rarely) or can it
float to a more aesthetic location?
5) Even text content might be unmoored -- why can't we have pull
quotes or sidebars in our articles?
6) What else? What other features of magazine, newpaper, or
encyclopedia design are we missing?
>From a technical perspective, I'd like to move eventually toward a
system with greater separation of layout and content (think of
something like adobe pagemaker), where changes to layout can be made
without editing the article text. But I'd also like to make sure that
the technical issues don't overshadow the actual goal:
* What beautiful designs would you like for article content?
* What tools could we build to enable these designs?
Eventually we'd like to boil this down into a concrete design for a
better image styling system, which seems like a reasonable first step
in revamping what mediawiki can do for designers. That RFC is
https://phabricator.wikimedia.org/T90914 -- ideally the RFC will be
guided by a concrete design for a specific article, say,
http://en.wikipedia.beta.wmflabs.org/wiki/Moon, so that the
implementation of the RFC can focus on building the capabilities
needed to execute that specific design. That way we're certain we're
building something useful and beautiful for designers and readers, not
just implementing something whose PHP code seems elegant.
--scott
--
(http://cscott.net)
Hey, all. I've noticed a common trend is to use grey text for your
emails. I know it's nice to make things prettier, but some of us don't
have terribly good eyes, or screens, or both. Could you please use a
little more contrast?
Thanks!
-I