Since the typography update got pushed we are now left with
* Changes to the table of contents
* Changes to thumbnails
* A cleanup of external links.
What should we do with these remaining changes?
We could either
1) Package them into a single new beta feature
2) Package each of them into individual beta features e.g. Vector
table of contents tweaks, Vector thumbnail tweaks, Vector external
links tweaks
3) Submit each of these as patches to Gerrit (unless there are any complaints)
4) Throw them away
Thoughts?
On Mar 29, 2014 2:17 PM, "Brian Wolff" <bawolff(a)gmail.com> wrote:
>
>
> On Mar 28, 2014 10:37 PM, "Quiddity" <pandiculation(a)gmail.com> wrote:
> >
> > First, the happy feedback:
> > The Thumbnail styles are currently being discussed at
> > https://en.wikipedia.org/wiki/Wikipedia:VPT#New_image_thumb_design
> > Onwiki feedback, and further ideas, encouraged!
> >
Hmm. (En) Wikinews has done something similar to that with thumbnails for
quite a while.
-bawolff
Hi all.
I apologize for cross-posting; I'm trying to reach all projects here, and encourage you to translate and spread this message to relevant village pumps. (I explain a tool here, some points, and provide you with a link where you can participate in the discussion I opened.)
The WMF Engineering Team is kindly working on Media Viewer, which would show a pop-up of some sort when you click an image. This tool is available for testing to those people who created an account, in Beta tab, on all projects. Like you may see the tool has a relatively high impact on average reader experience.
It came to my mind that the tool goes full-screen, which doesn't meet the "I stay on the article" expectation. I feel it may be important to an average reader to gain orientation.
I opened a discussion, with some people calling my idea a "metadata pop-up" rather than a "media viewer". I feel that may be good thing: the existing default opens a lot of image info and tells people what Commons is. I feel the media viewer should do something close to the same, with the advantage of not leaving the page, and some interactive means of viewing the image if the user clicks some buttons.
As opposed to that, a "Media Viewer" would show a bigger image and make use of space. But the mock I have is slightly bigger already, like the existing "File:*" page. I am not assuming that the reader wants a bigger image; I'm assuming he may also be interested (and it would be more transparent to) in reading some metadata, description, date, author.
Please see the discussion here and weigh in, basing on your preferences and Wikimedia projects experience. Your voice powers the future of the tool, and Wikimedia projects.
https://www.mediawiki.org/wiki/Talk:Multimedia/About_Media_Viewer#Please_do…
Regards,
Gryllida.
Hey,
Matt(superm401) merged my patch relating to animation to
mediawiki/core a few days back (yay!! \o/). I asked him if it made
sense to add some basic animations (slideUp, fadeInUp) to core so that
more extensions can make use of it. He said that not too many
extensions are using animation and thus it doesn't make sense to add
more things to core (I agree). I also feel that a lot of extensions
might not be using animations because the code is long, boring and
full of vendor prefixes. They probably *would* if it were easier to
add animations.
We have a Catch-22 here and we must solve it! I have a 5 step (evil) plan -
1. Brainstorm: Figure out where animation might make sense. Not
because animations are fun (somuchfun) but because they really aid
user interaction. I NEED YOUR HELP HERE!
2. Submit Patches: Once we agree that "extension A" (not necessarily
an extension could be any interface element) needs an animation I'll
code and submit a patch to it which will hopefully get merged.
3. Talk to Matt again and show him all the places where animations are
being used.
4. If Matt agrees, add those animations to core and submit new patches
to all those extensions to use the core animations.
5. PROFIT?? {$_$}
I know Pau and Gilles are doing this for the MultimediaViewer, it'll
be great if we could get more ideas. Looking forward to hearing from
everyone ¯\{^_^}/¯
--prtksxna
I downloaded the Android app for Wikipedia and had a play around with
it. One particular bit gave me a bad experience/first impression, so
here's some feedback for you.
I was completely puzzled yesterday when I tried logging into the
Wikipedia app for the first time. I added my login, password and then
hit the checkbox to remember my login.. only then to realise my
password was not visible in plaintext and that the label did not say
remember my login [1]. Now this password I use on a couple of sites (I
know that's bad but it's the case here). I never write it anywhere,
it's engrained in my memory. So to see it there in plain text freaked
me out and I was suddenly weary that I was in a public space where
people could see over my shoulder and to be honest I felt really
violated. I've now changed that password.
This was a really nasty experience for me. I'm trained to check those
remember login checkboxes, just as on a signup form I'm trained to
uncheck the add me to your mailing list box (which some forms abuse)
and check the i agree to terms and conditions boxes. I never read the
label.
I don't really get the need for such a feature though. No login forms
on the web in website or app form that I know of have such an option
as `show password` (please point me at some if they exist). It's not
clear to me what this achieves. It doesn't help me remember it for
example... all it seems to achieve is to give the impression that the
password is not important and can be shared.
[1] http://imgur.com/Rfc5QF9
Derk-Jan filed a bug
(https://bugzilla.wikimedia.org/show_bug.cgi?id=62924) about the focus
state for buttons. There is also a patch allowing the browser defaults
at https://gerrit.wikimedia.org/r/#/c/119998/
I was also somewhat concerned about this. As I recall (I think we
talked about this at one of the MediaWiki UI hack days), we decided to
tentatively go forward with hover == focus == bevel, but I think people
were open to revisiting it.
At any rate, I think he's right, and we should come up with a better
focus styling, either a custom one (probably better, but it should be
more distinctive than the current one, both from hover and from normal
state) or allowing the browser default.
Matt Flaschen
We've been playing around with early versions of this on mobile and have
been scrolling the window to emulate this - cc'ing the designers are I'm
sure this will excite them!
On Wed, Mar 19, 2014 at 6:41 AM, Gilles Dubuc <gilles(a)wikimedia.org> wrote:
> Thank for the tip, nice find!
>
> Unfortunately, it seems like it only works if the meta tag is present on
> pageload:
> - on pageload: http://ur1.ca/gvtgd
> - dynamic: http://ur1.ca/gvtfb (clicking the "foo" button adds/removes
> the meta tag)
>
> Which means we can't use it to make the chrome disappear when
> opening/closing media viewer.
>
>
>
> On Wed, Mar 19, 2014 at 9:42 AM, Ori Livneh <ori(a)wikimedia.org> wrote:
>
>> The newest release of Mobile Safari adds support for a new meta tag
>> property, 'minimal-ui', which allows you to hide the browser chrome. It
>> looks really great. I thought it might pair well with MultimediaViewer.
>>
>> http://darkblue.sdf.org/weblog/ios-7-dot-1-mobile-safari-minimal-ui.html
>>
>> ---
>> Ori Livneh
>> ori(a)wikimedia.org
>>
>> _______________________________________________
>> Multimedia mailing list
>> Multimedia(a)lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/multimedia
>>
>>
>
> _______________________________________________
> Mobile-l mailing list
> Mobile-l(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/mobile-l
>
>
--
Jon Robson
* http://jonrobson.me.uk
* https://www.facebook.com/jonrobson
* @rakugojon
Hey everyone,
There's no list for this, so I am assuming that if you've been invited to a
MediaWiki UI Hack Day, then you are interested, so you've been CCed. In
addition, the Design list is on this, so, please make sure to reply all.
Our team (Core Features) has been implementing MW UI as the basis of our
design with the new Flow extension. I think we're the first team to really
do that to this extent, and so I have some preliminary feedback to give
regarding this.
Design mockups have frequently called for the use of the "mw-ui-quiet"
class. Unfortunately, we've been running into problems with it. Often, the
use case is one of two scenarios:
1. In a *form*, next to a regular mw-ui-button.
2. Outside of a form, as a *link* with hover/focus context color.
Both of these scenarios have presented us with a serious problem: having a
content element with padding, but no discernible borders, makes aligning
these buttons impossible semantically. You are essentially forced to
override mw-ui-quiet CSS locally to have no padding for it to look
"normal", and then in that case, they are no longer button-like, but are
instead simple links.
Problems:
- *Exhibit A* - in a form: note the excessive whitespace between the
Cancel button and the others. Increasing the margin between buttons only
makes matters worse, and causes the button to look even further away than
intended.
* Solution:* We are now using a bordered-button for all form buttons in
Flow. We shouldn't be trying to hide buttons from the end user.
[image: Inline image 1]
- *Exhibit B* - independent links: they do not align to edges, and they
cannot match up to other inline-block or inline elements (we also lack a
mw-ui-spacer or such class to apply to other elements so that they may
inherit its padding and simulate it to even things out).
* Originally, we were using a CSS override to 0 the padding, but we
shouldn't have to do that for mw-ui elements in core if we want to maintain
a coherent style moving forward. Solution: *I've since changed these to
simple anchors with no special classes.
[image: Inline image 2]
Given these issues, I can't see any real semantic usage for mw-ui-quiet.
Can anyone give me a current usage that necessitates keeping it around?
In fact, I'm advocating that we remove it entirely from core, and instead
use a different quiet button that is somewhere between the current quiet
and the current regular buttons. I've been calling them "mw-ui-sleeper" for
now. Here is an example of it in action (on topic Reply, Preview, and
Cancel). http://area51.yar.gs/wmf/flow1/
Thoughts and concerns?
Thanks,
Shahyar
The fact we are having this conversation (regardless of what the answer is)
suggests that trello represents a significant hurdle to community
involvement, which i would consider a bad thing.
-bawolff
>
> On Mar 25, 2014 6:19 PM, "Quiddity" <pandiculation(a)gmail.com> wrote:
> >
> > Afaik, To comment on a card, one has to:
> > A) create a Trello account
> > and
> > B) be attached as a member to the particular Trello Board
> > [Or C) be assigned as a Trello-account admin]
> >
> > Ie. someone cannot instantly start adding comments, as soon as they
create an account. They have to be manually approved by one of the Board or
Trello-account admins.
> >
> >
> >
> > On 14-03-25 02:05 PM, Jared Zimmerman wrote:
> >>
> >> Yuvi, that board is public and accepts comments as long as you make a
> >> trello account. A community member and I worked through it.
> >>
> >> *
> >> *
> >> *
> >> *
> >> *Jared Zimmerman *\\Director of User Experience \\Wikimedia Foundation
> >> M : +1 415 609 4043 | : @JaredZimmerman <
https://twitter.com/JaredZimmerman>
> >>
> >>
> >>
> >>
> >> On Tue, Mar 25, 2014 at 2:03 PM, Yuvi Panda <yuvipanda(a)gmail.com
> >> <mailto:yuvipanda@gmail.com>> wrote:
> >>
> >>
> >>
> >>
> >> On Wed, Mar 26, 2014 at 2:27 AM, Jared Zimmerman
> >> <jared.zimmerman(a)wikimedia.org
> >> <mailto:jared.zimmerman@wikimedia.org>> wrote:
> >>
> >>
> >> If that can be communicated here
> >> https://trello.com/c/VKhizomH/3-icons-for-code-editor I can
> >> prioritize and figure out resources and time to get it done.
> >>
> >>
> >> Community members cannot edit or comment on Trello (at least that
is
> >> what Quiddity told me)
> >>
> >>
> >> --
> >> Yuvi Panda T
> >> http://yuvi.in/blog
> >>
> >> _______________________________________________
> >> Design mailing list
> >> Design(a)lists.wikimedia.org <mailto:Design@lists.wikimedia.org>
> >> https://lists.wikimedia.org/mailman/listinfo/design
> >>
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> Design mailing list
> >> Design(a)lists.wikimedia.org
> >> https://lists.wikimedia.org/mailman/listinfo/design
> >>
> >
> >
> > _______________________________________________
> > Design mailing list
> > Design(a)lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/design