647578 - [meta] twitter ui tracking

Status: RESOLVED INVALID

(Mozilla Labs :: F1, defect)

Description

[Bryan Clark (DevTools PM) [:clarkbw]]

Attachment: twitter web intents inteface breakdown

This bug is for tracking the twitter interface inside F1.

The most similar user experience twitter has is currently the web intents.  Attached is a breakdown of the web intents UI.
http://dev.twitter.com/pages/intents#tweet-intent

Comment 1

[Bryan Clark (DevTools PM) [:clarkbw]]

Getting started on the Twitter account.

Comment 2

[Bryan Clark (DevTools PM) [:clarkbw]]

Attachment: twitter account actions

I'm trying to wire up the twitter account according to the initial mockups and I have a few pieces that need some decisions.

We need to determine the layout of the chooser for public timeline vs. direct message.  The public timeline is simple because there are no requirements for recipients.  With the direct message we need to offer an input for the user to enter one or more recipients.  We also need to ensure that the person has entered a recipient and the recipient is a valid person they can DM.  Currently we're using the space beside the share button for this error message.  I'll attach a screenshot shortly.

With the layout of the initial mockup I think it's too tight of a space to add the dm recipient input directly to the right of the chooser.  I moved things around a bit to find a new layout, I'm leaning toward (3) which is pretty similar to how we have things now.

Comment 3

[Bryan Clark (DevTools PM) [:clarkbw]]

Attachment: current F1 invalid recipient - screenshot

here's a screenshot of what F1 is currently doing when a recipient is invalid.  This looks the same when nobody is specified at all, however the message is different; "you must specify a recipient".

Comment 4

[Bryan Clark (DevTools PM) [:clarkbw]]

Attachment: html link chooser demo

Here's my demo for the link chooser for the Twitter Account interface.

The next version of the Twitter account will include a default link copied into the message.

Currently we're automatically appending the link to a message as it is shared but this method, while having some observed usability gains for users not familiar with twitter, has a number of drawbacks for users who are familiar with twitter.  And this is how twitter shapes their interface so it's good to follow suit with that.

Users have a choice of a number of different links they could send in their tweets.

* shorturl/shortlink: http://flic.kr/p/9gGfFg
* canonical url: http://www.flickr.com/photos/madhava_work/5428455437/
* browser url: http://www.flickr.com/photos/madhava_work/5428455437/in/set-72157625999541262/
* and link shortening services

As you can see and try in the demo.  You can move the link anywhere in the textarea and choose a new link type which will replace the current link in the location you have it. I'm using a simple search and replace which works fairly well because it's simple and rather obvious.

Currently we only have the bit.ly link shortening service but we will very likely be expanding that list soon to other services and so this menu also gives those options.

I decided not to try labeling the different types of URLs because the label names don't really make a lot of sense to people.  Since all of the involved URLs should go to the same place it's really just a matter of taste and functionality.

The short URL services might end up looking more like http://bit.ly/XXXXX when they are first swapped in because we don't do the shortening until it is actually sent for sharing.  The XXXXX part gives you the proper character counting.

Comment 5

[Bryan Clark (DevTools PM) [:clarkbw]]

James is going to start work on this next week.

Alex, Stephen, if you have any more comments on the interface changes in attachment 526130 [details].  We're going to go ahead with the 3rd version unless there is an alternate you have. 

I've created bug 650417 for tracking the link chooser interface

Comment 6

[Alex Faaborg [:faaborg] (Firefox UX)]

looks good.  In the case of the user name not being recognzied in direct message, might want to have the error closely grouped with the field.  And maybe even have the inside of the field turn red (like the find bar, but ideally a better shade of red).

Comment 7

[Stephen Horlander [:shorlander]]

Attachment: Twitter Layout Idea #4

(In reply to comment #5)
> Alex, Stephen, if you have any more comments on the interface changes in
> attachment 526130 [details].  We're going to go ahead with the 3rd version unless there is an alternate you have. 

My reason for moving the destination chooser underneath the main message content was that it seemed like it would be the less common action. My hypothesis being that the most common case would be sharing directly to your public timeline. This way the first item encountered isn't seemingly a choice of where to send your message. Of course that could be the wrong assumption since I have no data to back to that up :)

I agree that in my mockup the field wouldn't be big enough. Unless changing to DM would move the share button down.

My only other concern with #3 is that the dropdown and the "switch…" link seem redundant.

(In reply to comment #6)
> looks good.  In the case of the user name not being recognized in direct
> message, might want to have the error closely grouped with the field.  And
> maybe even have the inside of the field turn red (like the find bar, but
> ideally a better shade of red).

Perhaps tying it directly to the field sort of like the HTML5 Form errors? (see attachment)

Comment 8

[Bryan Clark (DevTools PM) [:clarkbw]]

(In reply to comment #7)
> My reason for moving the destination chooser underneath the main message
> content was that it seemed like it would be the less common action. My
> hypothesis being that the most common case would be sharing directly to your
> public timeline. This way the first item encountered isn't seemingly a choice
> of where to send your message. Of course that could be the wrong assumption
> since I have no data to back to that up :)

Agreed, thanks for the alternate version. :)

> I agree that in my mockup the field wouldn't be big enough. Unless changing to
> DM would move the share button down.

We can do that.  There might be a slight jump in the panel since we don't have animation of sizing but that could be resolved later.

> My only other concern with #3 is that the dropdown and the "switch…" link seem
> redundant.

We had that in there for 'quick access', when there was only one other choice in a drop down, the other option is hidden for usage and space saving reasons.  The quick link gives a little bit of a on/off toggle so you can access the DM in a single click instead of opening a drop down chooser to select the one other item.  We don't have to keep it, but I wouldn't mind keeping the code around for some later A/B testing to see if it's actually used.

> (In reply to comment #6)
> > looks good.  In the case of the user name not being recognized in direct
> > message, might want to have the error closely grouped with the field.  And
> > maybe even have the inside of the field turn red (like the find bar, but
> > ideally a better shade of red).
> 
> Perhaps tying it directly to the field sort of like the HTML5 Form errors? 

I hadn't seen those until today, looks good to me if we can make it happen.  A lot easier than trying to find extra text space in the UI.


Last question related to this bug is about bug 650417 and where you'd like to land the link chooser.  We can't highlight the link in the text right now and make it some kind of a chooser.  In a future version if we switched to a more rich text like editor I think that's the direction we should go for. (in fact I'll file a bug about that today)  However right now the easiest solution is something like attachment 526166 [details] to help swap out the links for you.

Comment 9

[James Burke]

Attachment: Pointer to pull request

Comment 10

[James Burke [:jrburke]]

Attachment: Pointer to pull request

Comment 11

[Shane Caraveo (:mixedpuppy)]

Comment on attachment 529535 [details]
Pointer to pull request

per bug 654194, the use of less has to be decided on.
Otherwise, this pull adds some OS theme support

Comment 12

[Bryan Clark (DevTools PM) [:clarkbw]]

f1 is no longer an active project.  delete these messages by searching for: [closing_f1_project_bugs]