Design/Design Review

Wikipedia Mobile App
Notifications

Notifications could expand to fill the top section, with an accordian menu for other option

No muscle memory for clicking items in thr right drawer if things are moving

DI : move notification to bottom or have it be a second step to go to a list of notification

DI : reserve space for 1 or two notifications if they exsist and utilize that space for profile related or contributory things

Does notifications show on the main article screen?

Is it weird to have to drill down twice? main screen -> drawer -> notification

Two step might work for default experince

Could use a gesture, long or fast swipe to get directly to notifications

Will it degrate the reading experience to have notification count on the article screen

Will readers get that many notification?

Can we wait till you do a mode switch (differnet screen, change articles, etc) to send notifications?

Could we do something quieter for notification, a color other than red

Talk page notifications are the most important should come through immediatly

Should people be able to mark as read or archive notifications (echo-wide issue)

Chrome
Pinteret.app like chrome hiding?

Overly sheet of contributory actions?

Main article and "side notes," related content

Navigation
Unclear how to "go back" to where i was (back and forward buttons)

Article related is left drawer / my stuff is right drawer

Contribution should possibly moved to right drawer

Explore layouts for the two drawers

Currently

Left : contribute

Right : browse, my stuff

Proposed

Left : contribute, browse, article

Right : my stuff, notification, settings (?)

Swipes

Photo > infobox

Bottom of Article > related content

RTL > related content ( show forward in history options)

Lead image > infobox

Other images > gallery

LTR > back in history

Editing, Issues, and CTAs
If there is no access to text editing, and talk pages editors won't use it

how could you show the article issues direclty in the article ( in context )

would want to show where in the article the article issue is from the left drawer

Would it make sense to have a reader mode vs an editor mode

Discovery & Related
What articles are being read near where I am?

Test partial swipe behaviors to see if they are discoverable and understandable

DI : right drawer could have related articles AND related images

Gallery has access to images in the article and related images

What articles are being read near where I am?

Test how many right drawer options perform best

Highlighing imagery shifts perception to what other types of content we provide

Big question
Whats on the main landing page?

What is the startup exp?

Where do push notification go?

Can we have issues and contributory actions in context?

Does it make sense to have a reader vs editor experience?

Could the mobile app be reader only?

Offline/watchlist?

How much of the UX should be shared in mobile web?

Wikitrails
Reverse chronology and show above

what things start new trails

Start and end are important, but what about article I spend the most time on?

Where do I access? just sidebar or above current article

Red Links

 * Elaborate on what options are in the flyout for red links
 * Create new draft
 * Review draft
 * Translate
 * Linkify


 * Where would a user go when they click on a red link that has a draft associated
 * what would the new "this page doesn't exist" create it look like when a draft exsits
 * Consider surfacing the progress of a draft (e.g., a progress bar on the callout menu shown for rdlinks)


 * how do should at a glance that a draft redlink has content ? http://alistapart.com/article/customunderlines

Search

 * Don't index with Google
 * How do drafts show in search results?
 * Don't include in normal search, but allow for searching with advanced search or…
 * Does it make sense to have draft article appear in search specifically called out as draft you can contribute to.

Collaboration

 * "Ask for collaborators" "Invite people to help" or "Invite collaborators"


 * Tweet for collaborators


 * Short URL for collaborating


 * Collaboration workflows should be possible to be Flow-based:
 * pull flow content via API and present lightweight version in sidebar

Draft state

 * How do explain to users who type in an article name which redirects to a draft where they are and how this differs from an article
 * Should draft button be red? orange, yellow, a pattern.
 * Are we proposing changes in policy for how articles move from draft to main article namespace?
 * Talk to legal about the term "publish"
 * On the draft already exists page we shouldn't have two primary constructive buttons


 * "you may consider improving and publishing it"


 * Consider swapping the order of pending tasks and created X days ago


 * Consider combining the date created and the draft created text, or perhaps combine ( draft  v ) with the timestamp


 * Can you copy a whole article or a portion of an article into a draft space to work on it?
 * Edit conflict issues
 * How do you handle changes that happen after the draft transfer
 * Could we update the draft in a granular way


 * Does the draft and article namespace share names, e.g. can we insure that there aren't drafts or articles with the same name?
 * How do we support existing article creation process if a draft exists?
 * Maintain history of the edits done in draft


 * Reinforce the purpose of drafts on Save or Publish. In order to keep the editing workflow fluent, we need to show them only when it is really relevant (e.g., the user has pending tasks on this draft, or has not asked or collaborators before, even considering previous drafts).

Exposure to readers

 * To which level should we make aware readers of the content of drafts:
 * Present them as if the content is lacking with an additional clarification that some work is in progress (current approach in the designs).
 * Communicate that there is content there which is not published yet (a new kind of link? grey links? link+icon?). This requires to explain that they may encounter low quality stuff (to not affect user expectations and brand perception) and make it really obvious that a draft is not an article.
 * Communicate that there is content, and clarify later that the content is a draft.

The more we present drafts as regular content the more users we can get exposed to drafts (potential new editors) but the greater risk of confusion (intentional and not) between articles and drafts.

2013.12.03
Contributions Page
 * Think about the location of contributions
 * Topic based subscriptions
 * Prioritize and organize the information a little bit better
 * The color values need to be updated for added/ removed content

Flow - Visual Design
 * Move the dominant actions to the left to balance the interface better

Profiles Content Sharing
 * Simply the call to action to filling the profile out, avoid defaults.
 * Think about addressing the case for 'I don't even have a fully formed intent, we don't have an interest graph and we dont want defaults- how should a user fill a profile out? '
 * Experiment with an interactions that lets you share a very specific portion of an article (Rev i'ds, embedding, social networks)

Multimedia

 * having controls over the image is hard to discover when image is light or visually complex
 * due to aspect ration design control overlap is only a problem for some instaces
 * show underlays on controls when they appear over images
 * be intelligent about when to put the controls over the image and outside the image
 * specify keyboard behavior

Mobile

 * Do we need the double tap for controls?
 * Should the X to close be always availible
 * We should go back to the page the image was invoked on (actions within the image overlay are not written to the browser history)
 * How can we support zooming and panning within an image
 * for panoramas how would the user see 100% of the width if we pre-scale
 * how do you handle transparent images (checked background?)
 * White vs dark background for images

Mobile Search

 * Interlanguage search neat but maybe prominence could change
 * what is the value of showing articles in a language the user doesn't read?
 * can we even show result from other lang wikipedias?
 * lots of things on screen ( too many choices)
 * keep keyboard in mind for screen real estate
 * interlanguage links should have lower priority
 * is there a way to integrate images higher up
 * how would you integrate error states (did you mean)
 * How can we integrate wikidata results
 * Pau show mockup with interlanguage exact match
 * How do we educate users to what the purpose of other projects is within search results.

Mobile History

 * relationship between disjointed thread is unclear (more space)
 * Does the link context give enough value compared to muddying the design
 * Can I share out this journey ( via twitter )
 * Add to watchlist
 * Clear my history
 * link context, still unclear
 * section, preserve the section information when you reaccess the page
 * use whitespace to show relative time between access of articles
 * icon on the left could provide more actions
 * click on the search icon to reshow all of the search results you could have gone to instead

=== Microcontributions to wikidata ===
 * show character count on the description
 * needs to be able to see article while you write descriptions

=== Echo===
 * "Coeditor of X"

Mobile edits - linkify

 * Do we really want to to teach users how to write is wikitext
 * "add links to article" no "bluelink"
 * Why teach people to edit wikitext, this is a means to an end not the goals
 * tap on word to linkify
 * tap on word to request ref for sentence

Article History

 * Work with Jeph on timeline jephpaul@gmail.com
 * why these contributors
 * explain
 * what did they do?
 * unclear these are people

=October= =2013.10.30=

Grant Access to Apps

 * Try to eliminate the first step
 * Potentially separate out projects that you have already added into their own view (Break them out of list)
 * Think about Language Filters: If the high number of projects is due to the replication of a project per language (English Wikipedia, Spanish Wikipedia, Polish Wikipedia, and 300 more), we may consider not to represent information flat. Some options:
 * Allow user to only select a project and apply the settings for all the languages the project is in. This is good if language does not matter in this context.
 * Allow user to select the project which by default represents all languages, but allow to customise the languages later if the user wants to. For example, the user can expand the "Wikipedia (all languages)" item to select only some of them. This is good if language may be a factor for granting access.
 * Present a language filter, that allows to view only projects available in a given language, this will reduce the list. Thisis good if the common thing is to select only projects in my language.
 * Consider integrating the selector as a widget that acts in-place instead that in a modal window. This will reduce the number of steps for the user and avoid the blocking feeling of a modal window.

Flow on the Go

 * Icons Review - can we use icons without labels for actions like star and flag?
 * Think about whitespace management, currently there are many uneven breaks for the eye making the experience visually chaotic.

Profiles

 * Connect Intent and Talk
 * Think about how to surface contributions within the right navigation area.

=2013.10.22=

Limn Report Creation

 * why allow users to edit the unique ID
 * tags are new, would require some work to add
 * tags are not bi-directional, tags are added automatically but when removed they don't remove the associated data set
 * is preview useful?
 * how do I change color of sub-metrics?
 * how do I add new sub-metrics?
 * how do you publish the report, is the url of the edit screen the same as the url for the report view?

Unified Edit Toolbar

 * will it be a lot of work to have article issues templates appear in issues flyout
 * are the edit buttons non-rectangular
 * use of thank icon is a little weird
 * would it make sense to have "view code/view source" as a sub-mode within VE rather than split at the top
 * do we need a global pref that overrides sticky pref
 * I fixed this: doesn't remove template, but posts a message/template to the talk page about what I think I've done
 * can article issues be moved to some other kind of article metadata, rather than templates
 * "next" button should be blue (progressive action)
 * would this design for edit summary actually decrease the number of people entering an edit summary?
 * on save confirmation, force user to enter edit summary, like Googles untitled document warning
 * allow edit descriptions to be entered while the page is "saving"
 * "this is a minor edit" if no edit summary is entered
 * detect if user hovers over save button without entering an edit summary and auto expand or highlight edit summary control
 * for TOS agreement: try to have agreement at signup, for new users, for existing users catch them during edit
 * How to tie the new user edit exp. into getting started and/or guided tours
 * Pau to share sketches related guided tour/getting started
 * Does edit summary need a confirmation button?
 * Discard flyout actions should be flipped with primary on right, and
 * Discard/exit should probably be on the far left(?)
 * Trash can could scare uses "am I deleting the article?"
 * Can we construct a sentence out of the edit toolbar Help->Mode->Edit->Preview-Summarize->Save
 * when mode-switching choose [Discard & Switch] [ Save & Discard]