Closed Bug 647578 Opened 9 years ago Closed 7 years ago

[meta] twitter ui tracking

Categories

(Mozilla Labs :: F1, defect)

defect
Not set

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: clarkbw, Unassigned)

References

Details

(Whiteboard: [ui])

Attachments

(7 files)

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
Blocks: 642684
Depends on: 642916, 644356
Depends on: 648628
Depends on: 649738
Getting started on the Twitter account.
Attached image 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.
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".
Attached file 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.
Depends on: 650417
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
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).
Attached image 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)
(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.
Depends on: 650672
Blocks: 648927
Attachment #527440 - Flags: review?(mixedpuppy)
Attachment #527440 - Flags: review?(mixedpuppy) → review+
Depends on: 653002
Attachment #529535 - Flags: review?(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
Attachment #529535 - Flags: review?(mixedpuppy) → review+
Depends on: 654194
Component: Share: Web Client → F1
Product: Mozilla Services → Mozilla Labs
QA Contact: share-web-client → f1
Whiteboard: [ui]
f1 is no longer an active project.  delete these messages by searching for: [closing_f1_project_bugs]
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.