Yey! https://en.m.wikipedia.org/wiki/San_Francisco?mobileaction=stable
(Shame about the table of contents code leaking into stable on large screens though - I guess that fix is still on the train :/)
awesome.
*Jared Zimmerman * \ Director of User Experience \ Wikimedia Foundation
M : +1 415 609 4043 | : @JaredZimmermanhttps://twitter.com/JaredZimmerman
On Thu, Feb 6, 2014 at 11:18 AM, Jon Robson jdlrobson@gmail.com wrote:
Yey! https://en.m.wikipedia.org/wiki/San_Francisco?mobileaction=stable
(Shame about the table of contents code leaking into stable on large screens though - I guess that fix is still on the train :/)
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
woop woop!!
On Thu, Feb 6, 2014 at 11:18 AM, Jon Robson jdlrobson@gmail.com wrote:
Yey! https://en.m.wikipedia.org/wiki/San_Francisco?mobileaction=stable
(Shame about the table of contents code leaking into stable on large screens though - I guess that fix is still on the train :/)
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Great job team. Seeing Web and Apps get close with the Chrome design is wonderful. Now lets start thinking about desktop convergence. It's time.
--tomasz
On Thu, Feb 6, 2014 at 11:18 AM, Jon Robson jdlrobson@gmail.com wrote:
Yey! https://en.m.wikipedia.org/wiki/San_Francisco?mobileaction=stable
(Shame about the table of contents code leaking into stable on large screens though - I guess that fix is still on the train :/)
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Tomasz, sounds like you haven't seen one of our next beta features... http://unicorn.wmflabs.org/winter/ we're working hard on consistancy and convergence already.
*Jared Zimmerman * \ Director of User Experience \ Wikimedia Foundation
M : +1 415 609 4043 | : @JaredZimmermanhttps://twitter.com/JaredZimmerman
On Thu, Feb 6, 2014 at 11:24 AM, Tomasz Finc tfinc@wikimedia.org wrote:
Great job team. Seeing Web and Apps get close with the Chrome design is wonderful. Now lets start thinking about desktop convergence. It's time.
--tomasz
On Thu, Feb 6, 2014 at 11:18 AM, Jon Robson jdlrobson@gmail.com wrote:
Yey! https://en.m.wikipedia.org/wiki/San_Francisco?mobileaction=stable
(Shame about the table of contents code leaking into stable on large screens though - I guess that fix is still on the train :/)
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
On Thu, Feb 6, 2014 at 11:31 AM, Jared Zimmerman < jared.zimmerman@wikimedia.org> wrote:
Tomasz, sounds like you haven't seen one of our next beta features… http://unicorn.wmflabs.org/winter/ we're working hard on consistancy and convergence already.
It's got potential but it needs work to take advantage of a small screen.
Issues that i'm seeing right now
* no mobile resizing at all * article buttons overlap article text small screen * article icons overlap article text on small screen * search overlaps article text on small screen
What can my teams do to help to refine this so that its ready for mobile on day 1?
--tomasz
Tomasz your team (Kaldari, Juliusz and I) is helping build this via 3 beta features - typography refresh, fixed search header and compact personal bar :-).
There is a long way to go before we can make Vector responsive though. Chrome changes are the easiest right now.
On Thu, Feb 6, 2014 at 11:49 AM, Tomasz Finc tfinc@wikimedia.org wrote:
On Thu, Feb 6, 2014 at 11:31 AM, Jared Zimmerman jared.zimmerman@wikimedia.org wrote:
Tomasz, sounds like you haven't seen one of our next beta features... http://unicorn.wmflabs.org/winter/ we're working hard on consistancy and convergence already.
It's got potential but it needs work to take advantage of a small screen.
Issues that i'm seeing right now
- no mobile resizing at all
- article buttons overlap article text small screen
- article icons overlap article text on small screen
- search overlaps article text on small screen
What can my teams do to help to refine this so that its ready for mobile on day 1?
--tomasz
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
On Thu, Feb 6, 2014 at 11:18 AM, Jon Robson jdlrobson@gmail.com wrote:
https://en.m.wikipedia.org/wiki/San_Francisco?mobileaction=stable
I don't know if it's new in this chrome change, but the "search within pages" function doesn't work for me and/or I can't figure it out. Tapping that area or the icon in that just takes me to the top search result.
Also: we need to resolve the left-hand versus right-hand close (X) icon, if we're talking about desktop consistency. Almost every desktop web product I know, including us, favors close icons on the right. What is the rationale for mobile taking a different path?
Search within page as a site function or a browser function?
left close vs right, "Almost every desktop web product I know" can you give some examples? this discussion is as old as mac vs pc (since they flip their window close buttons)
*Jared Zimmerman * \ Director of User Experience \ Wikimedia Foundation
M : +1 415 609 4043 | : @JaredZimmermanhttps://twitter.com/JaredZimmerman
On Thu, Feb 6, 2014 at 11:35 AM, Steven Walling swalling@wikimedia.orgwrote:
On Thu, Feb 6, 2014 at 11:18 AM, Jon Robson jdlrobson@gmail.com wrote:
https://en.m.wikipedia.org/wiki/San_Francisco?mobileaction=stable
I don't know if it's new in this chrome change, but the "search within pages" function doesn't work for me and/or I can't figure it out. Tapping that area or the icon in that just takes me to the top search result.
Also: we need to resolve the left-hand versus right-hand close (X) icon, if we're talking about desktop consistency. Almost every desktop web product I know, including us, favors close icons on the right. What is the rationale for mobile taking a different path?
-- Steven Walling, Product Manager https://wikimediafoundation.org/
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
There seems to be some caching issues... I'm now seeing the old chrome.. Very weird.
On Thu, Feb 6, 2014 at 11:40 AM, Jared Zimmerman < jared.zimmerman@wikimedia.org> wrote:
Search within page as a site function or a browser function?
left close vs right, "Almost every desktop web product I know" can you give some examples? this discussion is as old as mac vs pc (since they flip their window close buttons)
*Jared Zimmerman * \ Director of User Experience \ Wikimedia Foundation M : +1 415 609 4043 | : @JaredZimmermanhttps://twitter.com/JaredZimmerman
On Thu, Feb 6, 2014 at 11:35 AM, Steven Walling swalling@wikimedia.orgwrote:
On Thu, Feb 6, 2014 at 11:18 AM, Jon Robson jdlrobson@gmail.com wrote:
https://en.m.wikipedia.org/wiki/San_Francisco?mobileaction=stable
I don't know if it's new in this chrome change, but the "search within pages" function doesn't work for me and/or I can't figure it out. Tapping that area or the icon in that just takes me to the top search result.
Also: we need to resolve the left-hand versus right-hand close (X) icon, if we're talking about desktop consistency. Almost every desktop web product I know, including us, favors close icons on the right. What is the rationale for mobile taking a different path?
-- Steven Walling, Product Manager https://wikimediafoundation.org/
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
On Fri, Feb 7, 2014 at 1:05 AM, Steven Walling swalling@wikimedia.org wrote:
Also: we need to resolve the left-hand versus right-hand close (X) icon, if we're talking about desktop consistency. Almost every desktop web product I know, including us, favors close icons on the right. What is the rationale for mobile taking a different path?
I'll note that both iOS and Android do 'back' (closest to 'close') on the top left, rather than the right.
On Thu, Feb 6, 2014 at 11:49 AM, Yuvi Panda yuvipanda@gmail.com wrote:
On Fri, Feb 7, 2014 at 1:05 AM, Steven Walling swalling@wikimedia.org wrote:
Also: we need to resolve the left-hand versus right-hand close (X) icon,
if
we're talking about desktop consistency. Almost every desktop web
product I
know, including us, favors close icons on the right. What is the
rationale
for mobile taking a different path?
I'll note that both iOS and Android do 'back' (closest to 'close') on the top left, rather than the right.
Good point. For the record: I'm actually okay if mobile and desktop diverge on this detail. It seems a compelling argument that on mobile we should pay more attention to the OS-level patterns than on desktop.
But if we're going to start migrating the close icon to the left in desktop products, as I have seen in some new designs, then you need to justify why and how we should switch over. There literally is not one left-hand close icon I can think of on the desktop site, if you don't count a few products we very recently designed (like Media Viewer) to follow the mobile pattern.
Other desktop sites, including Twitter, Facebook, Google properties, and others typically seem to use close on the right as well. I find myself always looking to the right for a close icon on desktop web, despite the fact that I am a longtime Mac user... Since the choice is apparently arbitrary then we should not be mixing things on desktop.