Hi,
A user in the Hebrew Wikipedia pointed out to me that it's uncomfortable to
her that after removing a page from the watchlist it is still displayed
there. It is gone after refreshing the watchlist, but she says that for her
it would make more sense if it disappeared immediately.
This is a design question more than a bug, so I'm asking here: what do the
designers think?
I can see pros and cons in both ways and I wonder how was the current
behavior decided: design and user testing or only the developers' intuition?
Thank you!
--
Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי
http://aharoni.wordpress.com
“We're living in pieces,
I want to live in peace.” – T. Moore
When the TOC is closed it would use the one on the left, and when open the one on the right (see attachment). (Reversed for RTL langs of course)
I think this would really help distinguish it from just being a "hamburger" type settings icon.
In the 2+ years I've been at the Foundation a recurring email thread /
bug reports have been in the form "X page doesn't render on mobile" or
"Can I have a nodesktop/mobileonly class?"
The problem is almost always an issue such as a huge margin left, or
some floating or fixed width css.
The answer to doing this is to provide a tool for wiki editors to
allow them to fix these kinds of problems.
There is an RFC [1] open with a suggested solution, and all that is
needed now is to implement it.
The general consensus was people wanted <style> tags. The original
proof of concept however used a separate page (Template:Foo would have
a corresponding stylesheet at Template:Foo.css) which was much easier
to implement.
I truly believe implementing this would reduce the bugs raised about
template specific problems, and lead to a better mobile experience. Is
this something the mobile team can schedule time for, or some other
team?
[1] https://www.mediawiki.org/wiki/Requests_for_comment/Allow_styling_in_templa…
Hello togeter, especially Android app developers :)
in OTRS, there is an android app user (https://ticket.wikimedia.org/otrs/index.pl?Action=AgentTicketZoom;TicketID=… in german) with a Motorola Moto G who has a high start time (about 50 seconds) of the app using WLAN (mobile network is ok). If he starts the app out of the browser, the app content comes instantly, too.
An API request in the browser (http://de.wikipedia.org/w/api.php?action=query&prop=revisions&format=json&r…) is executed without delay, too. Now i have no idea, what happens there, maybe there is something you know?
Thanks or advice :)
Freundliche Grüße / Kind regards
Florian Schmidt
Initial notes from yesterday's Apple announcements and release of iOS 8 &
XCode 6 final version to developers:
* iOS 8 final version available to developers, but not going out to the
public for another week or so -- gives us some more breathing room!
* XCode 6 can now be used to submit apps, so we can do a fully 8-ready
submission when we're ready. (The update currently in queue has fixes for 8
but is built for 7, which may or may not scale properly on the new devices.)
* iPhone 6 introduces a new slightly larger screen size; our existing use
of Auto Layout to handle variable screen sizes should handle this fine
* iPhone 6 Plus appears to introduce a third screen density/artwork scaling
resolution[1] as well as an even larger screen size. I'm investigating to
see if we need to scale up any of our SVG/PNG-based icons now for best
display. (Use of icon fonts should mean automatic high-resolution icons in
most places)
[1] What I've seen reported indicates rendering at 3x density, then scaling
down slightly to the final 1920x1080 output resolution. I'll see if I can
verify this in the Xcode simulators.
-- brion
Hi everyone,
tl;dr: To fit in compatiblity fixes for iOS 8, we're dropping some of our
planned iOS work from this sprint.
iOS 8 comes out on Tuesday 9th September, right in the middle of our
current sprint. Unlike on Android, it's a well acknowledged pattern that
iOS users are prolific OS upgraders, so we can expect a significant portion
of our user base to migrate to iOS 8 within days of the release.
We've discovered a number of compatibility issues between the app and iOS
8. Vibha, Monte and I met to discuss these, and we agreed that having fixes
for these in the iOS app is a top priority. This makes these issues a "drop
everything we're doing to fix them" situation. Kristen and I have yet to
figure out what planned work we need to drop from the current sprint to
make up for the extra work, and we're going to figure that out once we've
got all the issues documented in cards.
Vibha and I are going to do some more comprehensive testing of previously
identified pain points for cross-version compatibility (e.g. search), and
any additional issues we identify will also be prioritised relative to our
current work.
To see what we're working on iOS 8 compatibility wise, go to the sprint 39
Trello board
<https://trello.com/b/ylAF2Yey/mobile-app-sprint-39-navigation-9-1>, and
apply the red "iOS 8 compatibility" filter which we've added specially to
track these issues.
Let me know if you have any questions!
Thanks,
Dan
--
Dan Garry
Associate Product Manager, Mobile Apps
Wikimedia Foundation
Since we had the luxury of having several people in the office,
Trevor, Juliusz, Rob Moen, Ed Sanders, Shahyar, May, Monte and I sat
down to talk about the problem we currently have of having no standard
way to create icons. Here is my write up of this meeting, again, if
you attended please add/correct me on anything and if you were not
please ask for clarification where needed.
Currently we have two modes of creating icons in MediaWiki
1) Using a font
2) Using SVGs with PNG fallbacks
and the markup varies depending on what extension you look at.
We discussed both approaches and advantages and disadvantages of each.
One of the major disadvantages of the WikiFont is the additional HTTP
request it creates to download the font and cannot be embedded in the
stylesheet using data uris like SVGs can (due to URL size
restrictions).
One of the major advantages of WikiFont is you can design a grayscale
icon, and style it using font colour. Shahyar was happy to move Flow
to using SVG based fonts if we could build grayscale SVGs and change
their colours using ResourceLoader. One concrete example is when you
have an icon used in a constructive anchor. The icon needs to be
green, but when hovered over a lighter green.
Another advantage brought up by May was that currently she finds it
much easier to build icons in this way, and that having to maintain
separate coloured versions of the SVGs is a pain point to her.
We decided that we should push towards using SVGs that can be built
into fonts for the purpose of the app.
As next steps
1) Monte to explore using SVGs in the Wikipedia apps. He will create
font from SVGs. He will work with May to ensure her workflow is as
easy as before.
2) Trevor is going to look into how we can automatically generate
different colour versions of SVGs and automatically create PNGs from
them.
3) I am going to aim to agree on a standard icon HTML markup for
mediawiki ui. We still have an issue with the fact that everyone is
using different HTML markup to create icons. After reviewing all our
current approaches [1] it was clear that we were relatively closely
aligned and that it simply is a case of agreeing on class names.
We aim to get all the above done by Sept 15th, 2014 so please poke us
on the mailing list if you haven't had a follow up then.
Full disorganised notes can be found here [2].
[1] https://www.mediawiki.org/wiki/Icon_standardisation
[2] http://etherpad.wikimedia.org/p/Icon_standardisation
Forwarding to mobile-l to keep this conversation public.
In short, yes. The ToC peekout was a cool idea, but really it looks more
like a bug than anything else. But, it's okay that it hasn't worked. The
Mobile Apps Team just championed rapid development and experimentation, and
that makes us awesome! \o/
I think going with the ToC onboarding for now is fine. The remaining work
there is to get it to a state that we're happy with. Then we can see how
people respond once that's rolled out, and use that to gate whether we want
to further experiment with other ideas.
Thanks,
Dan
On 9 September 2014 16:09, Vibha Bamba <vbamba(a)wikimedia.org> wrote:
> Hi team,
> Here is a roundup of comments from discussion with design team and a few
> other people. In theory the idea makes sense as a continuous idea (Dan came
> up with this, recognizing that he forgets to invoke the TOC even though he
> is aware that it exists)
>
> 1. It feels somewhat unpredictable. As a user I'm not sure when this thing
> will come out because I can't develop a pattern around it. It seems to
> behave differently during up-scroll and down-scroll
>
> -When you pause scrolling to grab it, it sometimes doesn't come out or
> disappears and it feels like you can't get a hold of it. (This makes sense,
> because we don't want it to persist if a user has found a section they want
> to read. So the delay for dismiss may need to go up a little)
>
> - As a user I expect it to come out all the way or not at all when you
> predict that I need this menu.
>
> -------
>
> Some users brought up that this is an uncommon pattern. While that doesnt
> bother me at all, I do believe we want it to feel right i.e predictable
> I think we have a great start here but we have some decisions to make as a
> team:
>
> -We can iterate on the speed and timing and test it
> -We can wait to see how the TOC onboarding does and tackle this after that
>
> Dan, we can discuss this next week after the full text search meeting.
>
> --------
>
> ----
> Vibha Bamba
> Senior Designer | WMF Design
>
>
>
>
>
>
>
--
Dan Garry
Associate Product Manager, Mobile Apps
Wikimedia Foundation
Shahyar, Juliusz, Trevor, Kaldari, Roan and I sat down yesterday and
talked about the future of skins. Hopefully this mail summarises what
we talked about and what we agreed on. Feel free to add anything, or
ask any questions in the likely event that I've misinterpreted
something we talked about or this is unclear :)
Specifically we talked about how we are unhappy with how difficult it
currently is for developers to create a skin. The skin class involves
too many functions and does more than a skin should do e.g. manage
classes on the body, worry about script tags and style tags.
Trevor is going to create a base set of widgets, for example a list
generator to generate things like a list of links to user tools. The
widgets will be agnostic to how they are rendered - some may use
templates, some may not.
We identified the new skin system will have two long term goals:
1) We would like to get to the point where a new skin can be built by
simply copying and pasting a master template and writing a new css
file.
2) Should be possible for us in future to re-render an entire page via
JavaScript and using the modern history push state re-render any page
via the API. (Whether we'd want to do this is another consideration
but we would like to have an architecture that is powerful enough to
support such a thing)
As next steps we agreed to do the following:
1) Trevor is going to build a watch star widget on client and server.
We identified that the existing watch star code is poorly written and
has resulted in MobileFrontend rewriting it. We decided to target this
as it is a simple enough example that it doesn't need a template. It's
small and contained enough that we hope this will allow us to share
ideas and codify a lot of those. Trevor is hoping to begin working on
this the week of the 2nd September.
2) We need a templating system in core. Trevor is going to do some
research on server side templating systems. We hope that the
templating RFC [1] can get resolved however we are getting to a point
that we need one as soon as possible and do not want to be blocked by
the outcome of this RFC, especially given a mustache based templating
language can address all our current requirements.
[1] https://www.mediawiki.org/wiki/Requests_for_comment/HTML_templating_library
Hi everyone,
The iOS 8 testing notes are available here:
http://etherpad.wikimedia.org/p/WikipediaiOSTesting (mw.o page dump
<https://www.mediawiki.org/wiki/User:DGarry_(WMF)/Apps/iOS/Testing20140909>
).
Note that as we didn't have enough test devices this ended up being more
general, but there were a few issues with the iOS 8 build in particular
that were identified:
- Today doesn't work properly. If you try to scroll after tapping Today,
the web view shoots down then gets stuck. (iPhone 5S, iOS 8 build 4.0.2 -
5th September 2014)
- In some (unknown) cases, summoning the ToC can cause the webview to
resize as expected, but the ToC to never appear and the ToC button to stop
working. The only workaround is to manually close the app. (iPhone 4, iOS
7, build 4.0.2.1 - 6th September 2014)
- A few esoteric crashes relating to search (e.g. 'click lots of
bluelinks' or 'click lots of search results') that I've so far been unable
to reproduce.
Thanks,
Dan
--
Dan Garry
Associate Product Manager, Mobile Apps
Wikimedia Foundation