Bugzilla – Bug 13175
design scrub of facebook app
Last modified: 2009-10-05 14:35:51 UTC
I need to look closely at Andy's facebook app implementation and propose any needed design changes.
Is it okay to comment here on the facebook app? I didn't want to open a new bug since it's probably still a work in progress. Anyway, I was looking at it last night on the Controller with r7084. Looks good, so far! One thing I had trouble with was reading the scrolling lines on the small controller screen. Most items I could not read entirely before the screensaver came on, and then it put me back to the beginning with the scrolling. So my thought was that there needs to be a way to push right so a line item can be read on a full page. Also, the photos could be displayed to fill the screen better. i.e. landscape pictures rotated to landscape mode on the Controller.
Thanks Sue, dealing with the scrolling text is definitely on the list...
This was a lot more work than I/we thought. Lots done though. Figures out layouts/comps with Noah today, writing up mini-spec for Any / Tom / Ben tonight
Most issues defined over email, expecting follow-up questions from Andy/Ben/Tom. Noah is putting together screen comps for "my wall" and "news feed" screens.
Nothing to add to current definition, but will be available for support/questions etc.
Please post spec here.
Created attachment 5694 [details] News Feed (Baby)
Created attachment 5695 [details] News Feed (Jive)
Created attachment 5696 [details] Wall (Baby)
Created attachment 5697 [details] Wall (Jive)
2 parts to this I think: ------ 1. - "Stacked" title bars for select apps. I believe Noah has had assets and guidelines for this in SVN for a while. The idea is that on facebook and other "well-branded" apps (Pandora, Rhapsody, last.fm, flickr, SIRIUS, etc - forget the exact full list, but it should be in the asset set), we use a different treatment for the title bar (see "news feed" attachments). There are 2 minor variations to this title bar. a - On the "app description" page (in the app gallery - the screen with the long description and "install facebook" option etc) and on the "home screen" of these apps, this title bar is standard height, but you substitute in the graphic asset instead of the usual text-based title. b - On almost all other screens inside the app (i.e. screens under the home menu), you use the title bar treatment shown in the "news feed" attachment above. This type of title bar is taller than normal (see reference for exact height) with a 2-line display. The top left corner shows the app logo, the bottom left corner shows the name of the current menu, and the bottom right area shows the user's name/username/email (whatever is appropriate for the service, in this case facebook would show your First name and Last name.) (The username bit is a nice-to-have but not strictly required for 7.4). ------ 2. News Feed + Walls The News Feed has the title bar type discussed in "1-b" above. Each line item is the same height (82px I think, refer to the guides in SVN). Each post in the news feed displays the following: - profile pic of that person (standard icon size) - first and last name of the user - the "dot" separator we're using for album/track titles on now playing - the text of the post. (the top line breaks on the "jive" version are coincidental) If the text from the post is truncated, then: - we should truncate gracefully if we can (...) and make that item selectable. - if the item is pressed, the user is taken to a screen with the full text of the post. - Comments should NOT be supported in this version. That requires more design work, and I'd strongly prefer to add that functionality only when we get time to do it right.
Finally, a note on Walls - Walls (both "my walls" and friends' "walls") should use the "News Feed (Baby)" and "News Feed (Jive)" layout templates (of course, the title of those screens should be "[firstname lastname]'s Wall" instead of "News Feed.") PLEASE IGNORE THE INCLUDED "WALL" REFERENCE SCREENS IN THIS BUG. I just caught a semi-serious issue with that design, which I can explain later (it's an interaction design issue with facebook that I misunderstood). Apologies for the confusion. To repeat: both the news feed and the "walls" should be based on the attached "news feed" designs. IGNORE the "wall (baby)" and "wall (jive)" attachments.
I propose we drop the right-justified text, and just make the title: <FB logo> News Feed - First Last This is easy from the SN side, not sure how much work that title image is on the SP side.
== Auto-comment from SVN commit #7142 to the network repo by andy == == https://svn.slimdevices.com/network?view=revision&revision=7142 == Bug 13175, use Unicode bullet between name/message, add multiline text style
== Auto-comment from SVN commit #28311 to the slim repo by andy == == https://svn.slimdevices.com/slim?view=revision&revision=28311 == Bug 13175, untested custom windowStyle
I met with Facebook last week and showed them the app. Overall, they really liked it, but they did have some feedback including one "must fix" item. Apparently we are using the wrong method to post the user's story to their Wall when sharing an item on Facebook. I'll add some of the medium- and low-priority (i.e., _not_ required to launch) items as an enhancement bug. Andy, here is what they said we need to do to get approval to launch (I'm guessing this will be a trivial change for you): Use stream.publish for story publishing (http://wiki.developers.facebook.com/index.php/Stream.publish) and follow the following Feed policies (http://wiki.developers.facebook.com/index.php/Additional_Policies_Governing_All_Applications_and_Developers#5._Feed_Policy). Notably, a "status" or "user_message" must be explicitly typed by the user. It can't be canned text. You should place your story text in the story body as explained on the Stream.publish Wiki page.
You're kidding right? People have to enter their own message?! No one will ever use this if that's the case.
No, that's not what they are saying. It's fine to present the user with the three different strings like we're doing today. What needs to change is the method you are calling on Facebook to post this to their Wall. As they say below we should place our story text in the story body as explained on the Stream.publish Wiki page.
OK I'm really confused. I am already using stream.publish with the following arguments: call( 'stream.publish', message => $post, action_links => qq|[ {"text":"$action_text", "href":"http://www.logitechsqueezebox.com"} ]|, ); Why did they think I was using something else and what is wrong with this?
They could tell just by looking at what we're posting, and the design/layout of how it appears. Apparently whatever we're doing is appearing the same as if the user actually typed it themselves. Instead, we need to be posting it as coming from our "app." Take a look at your own Wall at the post you made on 7/16 for "We Choose the Moon." You personally typed "Neat site, cool idea." Whatever app you posted it from provided the rest of the copy, starting with "Wechoosethemoon.org is an interactive experience..." Our app needs to post in this second area. Later, if we want to, we can _also_ allow users to add their own personal comment in addition to what our app posts (like you did in the example above). Do you want me to ping them to find out the exact arguments/calls you need to be using to do this if it isn't clear from their documentation?
Our posts do show as coming from our app (hence the little Logi logo). I have no idea what I'm doing wrong, so yes, please find out.
Message in to FB seeking additional clarification re what arguments we should be using to meet their requirements given the way our app works.
Feedback from FB: The "message" attribute of stream.publish is meant to be for the text the user types in themselves. You guys should put your story "body" (e.g. "Jeff is listening to the Arctic Monkeys") in the "attachment" attribute. Check out the following documentation and let me know if things are still unclear: http://wiki.developers.facebook.com/index.php/Stream.publish http://wiki.developers.facebook.com/index.php/Attachment_%28Streams%29
== Auto-comment from SVN commit #7185 to the network repo by andy == == https://svn.slimdevices.com/network?view=revision&revision=7185 == Bug 13175, use attachment instead of message for FB post
Created attachment 5777 [details] Sample post using attachment OK, what this does is let you create a bold title and a second/third line caption/description. Right now I have the message posted as the title and no caption, so it will appear bold and looks a little strange. Here is a screenshot of all 3 items.
Based on the fields we have at our disposal in the body of the attachment attribute, we should display the following on Facebook.com: Title (in bold): FirstName just shared music from their Squeezebox Source: www.mysqueezebox.com Caption: None/Do not use Description: "I'm listening to [song]/[album] by [artist]." Image: Image/icon of the Squeezebox player model they were playing music from. If necessary, we could defer display of the image as a post-launch enhancement.
The product images in the square bubble on SN aren't really the best for Facebook. Images with a plain white background look best. I will link the images from logisb.com unless you want to send me some different ones.
== Auto-comment from SVN commit #7198 to the network repo by andy == == https://svn.slimdevices.com/network?view=revision&revision=7198 == Bug 13175, updated post text, product images
Can you post a screenshot?
Please confirm these images are OK. I also could use images for Controller by itself, Receiver by itself, Slimp3, SB1/SB2. By default the image used is Baby if one of these doesn't match. baby => http://www.logitechsqueezebox.com/images/squeezebox_radio_red_small.jpg boom => http://www.logitechsqueezebox.com/images/boom_facing_right_196x193.jpg controller => http://www.logitechsqueezebox.com/images/duet_193x140.jpg fab4 => http://www.logitechsqueezebox.com/images/touch_facing_right_2.jpg receiver => http://www.logitechsqueezebox.com/images/duet_193x140.jpg squeezebox3 => http://www.logitechsqueezebox.com/images/sb3_front_500.jpg transporter => http://www.logitechsqueezebox.com/images/transporter_232_132.jpg
Created attachment 5785 [details] Sample post with image
Also note the image links to the product page.
Adding Noah to the cc. Hmmm... Given the expected short length of our users' posts, I think the device image looks really large. I'm also a bit worried that the Now Playing info, which is more visible on some player images than others (especially on Classic) might actually throw people off since it won't match what the user is "sharing". Other than that, I really like the idea of showing the device and think it looks quite nice. Maybe both can be solved by just using smaller images. That way the relative size difference between the image and the post isn't so large _and_ the Now Playing screen will be smaller/less legible. What do you guys think?
I'm sure people will realize they are canned product shots and not worry about the NP text. But yeah I agree it's too big, we can reduce the size easily.
Ben: I tested multiline_text_list and it's coming through fine, but only if controlling an SP player. It brings up another issue, which is player-specific formatting of menu items. When controlling a non-SP player you will get the non-SP version of the menu.
Can we send a menu:menu flag in the request from an SP player and format the response based on that rather than what kind of player the $client is? That's how it's done throughout the rest of SP requests...
Yeah that would work.
Andy- couple ?'s 1. Will the text always top align to the image? 2. Have we decided to use only 2 lines?
(In reply to comment #38) > 1. Will the text always top align to the image? Yes I believe so. > 2. Have we decided to use only 2 lines? Yeah, that was based on Seth's comment #26.
Created attachment 5786 [details] Ref artwork - redesign of elements v2
Created attachment 5787 [details] Ref artwork - redesign of elements v3
That looks good. Let me know where I can get those new product icons.
I can upload them to SVN? I would like to create them to size so that I can adjust the sharpness/color on a case by case basis...
Sure I think it should be OK to put them in your usual MasterIcons directory.
Last question:) Are we supporting Facebook on the following: Slimp3 SB v1 & v2 SB Classic Transporter SB Boom
Yes Facebook will work on all products, so it would be good to have the full icon set.
== Auto-comment from SVN commit #7418 to the jive repo by bklaas == == https://svn.slimdevices.com/jive?view=revision&revision=7418 == Bug: 13175 Description: first checkin to handle multiline text window for (initially) facebook, QVGA skins only for now 3 lines of text in the menu item are a textarea and not a label widget, so text will wrap to view the entire text of one of these textareas, press + to load text in a context_menu styled popup (note: this means that there will be no context menus for multiline_text windows, but we needed some way of reading whole posts) issues to overcome yet: scrollbar unwanted in menu item textareas (Tom is looking at this) textarea for lower menu items show underneath status bar (don't understand this, but it doesn't manifest in controller skin) scrollbar in popup window when text spills over is poorly laid out (scrollbar comes from textarea widget; appears there is no control over a textarea scrollbar layout) popup window for full text of post complains about unconsumed action on close on the console
Created attachment 5788 [details] Ref artwork - w/ player icons formatted for Facebook (top 5) I will be committing the player icon assets for Facebook to SVN shortly. Look for "icon_name_fb.png"
Thanks! I wonder if we need one for Receiver, or if just showing the Controller icon for that is fine.
== Auto-comment from SVN commit #7420 to the jive repo by bklaas == == https://svn.slimdevices.com/jive?view=revision&revision=7420 == Bug: 13175 Description: don't let fab4 skin be completely broken for multiline text style this will need a full audit, but after 7.4 10' UI has no code at all for multiline yet, and won't until post-7.4
== Auto-comment from SVN commit #7228 to the network repo by andy == == https://svn.slimdevices.com/network?view=revision&revision=7228 == Bug 13175, updated post icons
Andy, I think we only want to show devices that have an *input*. Regardless of where the info might be coming from it is the device that the user selects "post" and should appear on facebook...so receiver would not be necessary.
== Auto-comment from SVN commit #7422 to the jive repo by tom == == https://svn.slimdevices.com/jive?view=revision&revision=7422 == Bug:13175 + 3 Description: - support no scrollbar for textarea, have SB textarea items not us scrollbar
== Auto-comment from SVN commit #7423 to the jive repo by bklaas == == https://svn.slimdevices.com/jive?view=revision&revision=7423 == Bug: 13175 +8 Description: Incremental checkin in support of Facebook window styling. Close, but not there yet.
== Auto-comment from SVN commit #7425 to the jive repo by bklaas == == https://svn.slimdevices.com/jive?view=revision&revision=7425 == Bug: 13175 Description: pressed and locked states for multiline_text_list items
== Auto-comment from SVN commit #7428 to the jive repo by tom == == https://svn.slimdevices.com/jive?view=revision&revision=7428 == Bug:13175 + 3 Description: - avoid drawing in "hidden" menu item.
== Auto-comment from SVN commit #7454 to the jive repo by bklaas == == https://svn.slimdevices.com/jive?view=revision&revision=7454 == Bug: 13175 Description: don't let textarea spill over context menu window asset when using + key to bring up full post
I believe we're done with this now. hooray facebook LOL
== Auto-comment from SVN commit #7457 to the jive repo by bklaas == == https://svn.slimdevices.com/jive?view=revision&revision=7457 == Bug: 13175 Description: fix for right asset in selection box
Propose adding support for different menu heights. Menu Heights would be driven by text copy size and potentially have a MAX character limit set before truncating. Most notably for areas such as News Feeds.
It would be a major effort to support varying menu heights, and needs a separate bug.
Just got some feedback from the tester at Facebook. I'm going to open a new bug re most of the enhancements they have suggested_that we make. However, they've seen one issue that looks like a possible show stopper. Here's what they had to say: "When trying to "Share this [current song] on Facebook", after selecting the story type, an error is returned (code 100: img objects must have valid 'src' and 'href' attributes)." Have we seen this issue? If so, can we try to resolve this one today? They are waiting on this before pushing their legal team to sign the auth.login/Extended API agreement... Also, here are a few other bits of feedback that would be pretty nice to address before launch if possible: - Sometimes the screensaver isn't able to start and displays an error. - Sometimes the screensaver displays a generic FB dude image. Not totally sure why but should be preventable. - If there are no comments for a given story, you probably shouldn't show the "(0)". - Is there any way to have the detail view (when you click into a story) scroll vertically? The scrolling text is kinda crazy. - For comments, please show the person's name first (not last). - Context menu should say "Share on Facebook" not "Share this on Facebook" They had more items, but they are either not particularly important or seem like a lot of work. Like I said, I'll open a separate bug for those and target for 8.0 (or 7.5 or whatever we're calling the Fab4 release).
I think that error can occur if you try to use Share on Facebook before actually adding an FB account. Tell them to work around that by adding an account first, and I will fix it soon.
Reopening to address these issues. Some of those are won't fix items though I think.
Some more feedback from the FB tester after I told that error can occur if you haven't yet tied credentials to the app... "No. I'm logged in and still getting that error. I added my account from the device." He also had this additional bit of feedback, re viewing your FB friends' favorite music: "One other quick thing is I'm seeing weird behaviors with the Favorite Music section on peoples profiles. Sometimes upon clicking "Favorite Music" it says "Could not parse", sometimes it says "function: 0x5fd0a8" as a menu item, and sometimes it works. May have something to with the case where someone doesn't have any favorite music listed."
== Auto-comment from SVN commit #7373 to the network repo by andy == == https://svn.slimdevices.com/network?view=revision&revision=7373 == Bug 13175, provide error message if going to Share menu without an account
== Auto-comment from SVN commit #7374 to the network repo by andy == == https://svn.slimdevices.com/network?view=revision&revision=7374 == Bug 13175, don't show comment count of 0
== Auto-comment from SVN commit #7375 to the network repo by andy == == https://svn.slimdevices.com/network?view=revision&revision=7375 == Bug 13175, show name first in comments, also turned comments into a multiline text line
== Auto-comment from SVN commit #28559 to the slim repo by andy == == https://svn.slimdevices.com/slim?view=revision&revision=28559 == Bug 13175, change text to 'Share on Facebook'
== Auto-comment from SVN commit #7377 to the network repo by andy == == https://svn.slimdevices.com/network?view=revision&revision=7377 == Bug 13175, handle case of user not having any favorite music
> Sometimes the screensaver isn't able to start and displays an error. If the screensaver can't get an initial image I guess it returns an error. > Sometimes the screensaver displays a generic FB dude image. Not totally sure why but should be preventable. This happens when you are using the news screensaver and the news item comes from someone with no picture. The generic image is pretty low-res, got a better suggestion for something to display? > Is there any way to have the detail view (when you click into a story) scroll vertically? The scrolling text is kinda crazy. No, this is an SP limitation. I think everything else is fixed, so marking this fixed again.
Thanks for knocking all of these out Andy. I still think viewing the Wall posts/comments needs some tweaking. When clicking through to read long Wall posts, would it be possible to use the same SP template we're using for the Queen lyrics? We could then include a menu item at the end of the original post to view any comments (if there are any). That "view comments" menu would then take you to a screen that uses the multiline text line for each comment (as you're doing now). And if any of those comments are too long to fit on the multiline text line, they could link through to the same "Queen lyric" type of template to read the entire comment.
You can already press "+" to read the full text of the posting. Is that not good enough?
(In reply to comment #73) > You can already press "+" to read the full text of the posting. Is that not > good enough? I know it's probably frustrating eking out the final details of this thing, but the news feed post system is still a bit messed up. If a post is not truncated, it should not have a ">" character, and it should not be selectable. If it is truncated, you should be able to select it with a knob press and read the full post on the next screen (I think this is what Seth is suggesting with the "Queen lyric" template). It would be nice to be able to do some formatting on this screen but I was refraining asking for that. Instead it's sufficient for now for the title bar on that screen to be the poster's name, and to simply have the text I had asked to remove comment support from this initial version until we had time to design/implement it properly. It should be totally fine to add that back in a later release. Seth has some good thoughts in comment 72, but even that design suggestion has problems. The context menu for a news feed/wall post had not been defined. I was imagining, eventually, that this menu (if built) would allow for "liking" a post, and performing actions related to the person who posted the comment... Apologies for any confusion. -------------
The requested feature is an SP-side thing, so assigning to Ben.
SP doesn't know if an item is truncated when the menu item is created and therefore it can't dynamically style to suit this request. This goes beyond what can be provided for 7.4, the + for the whole comment works and we are up against an immovable deadline. Removing comment support is not my hot potato, so back to Andy.
Comment support is fine IMO, why remove it?
+1 to Andy's last comment
(In reply to comment #78) > +1 to Andy's last comment One fix just appeared in an upgrade (r7656) that I had never seen when I wrote my last post: formatting was added to the posted comments (it wasn't there earlier today, they were just single-line displays). The main problem here is that the interaction is backwards. Right now, you press "+" to view the full post, and selecting the item displays it's contents (if it has any). This is not what was asked for, and it currently results in a confusing design. If I see a comment, and it's truncated, and there is an arrow next to it indicating that I can navigate into it, my assumption is going to be that navigating into it is going to reveal the entire post. That's not what is happening now. What was originally asked for, and what I'm still asking for, is this: - truncate each post and add a ">" character if it's too long to fit. Pressing the item should take you to a screen that displays the whole post. Having the username and user's photo at the top of that screen would be great, but I guess that needs to wait for a future version. For now, we can have the user's name in the title bar and the full text of the post underneath. - if the entire post fits without needing to be truncated, then there is no reason for a ">" character next to it. - remove comment support in the 7.4 version. We can add in the proper design for 7.4.1. ----------- I understand we're all frazzled right now, but I find it hard to believe that you guys honestly think the current design is in any way intuitive. It's confusing as hell - there is no mention that (x) refers to comments. The comment screen is not labeled "comments." and the "+" button behavior is inconsistent with how that button works in most cases - logically, pressing "+" on a post should pull up metadata and options regarding that post and/or the user who posted it. ("I like this post," etc.) ------------ I was deferring comments to try to make life easier for everyone. The correct design solution is probably a fair amount of work, and we have no time for that. I think it's fine for us to start with a small feature set and add to it gradually, instead of tackling too much at once (I fear we may already have done so anyway).
== Auto-comment from SVN commit #7394 to the network repo by andy == == https://svn.slimdevices.com/network?view=revision&revision=7394 == Fixed bug 13175, disable comments
== Auto-comment from SVN commit #7660 to the jive repo by bklaas == == https://svn.slimdevices.com/jive?view=revision&revision=7660 == Bug: 13175 Description: make go drill into full comment, which is presented in a CM-styled window
> The main problem here is that the interaction is backwards. Right now, you > press "+" to view the full post, and selecting the item displays it's contents > (if it has any). This is not what was asked for, and it currently results in I meant "comments," not "contents," sorry.
Just got the (final?) feedback from Facebook. In short, we are generally good to go and they are going to push their legal team to sign the Extended API agreement, BUT there are a few areas they have some issues with and two (semi-related) things that they feel need to change before we launch. These relate to "infinite sessions" and switching between different user accounts. I may be wrong, but I don't think either of these will be too hard to do. Your thoughts Andy? Here's what they had to say: "the big thing that needs to get fixed before launch (regardless of whether or not you have on device login) is how the Squeezebox works with multiple Facebook accounts. Maybe we can chat more about how this works (give me a call Monday if that's easiest). Basically, if you're going to use an infinite session (after on device login), you need to let the user know that and make them aware that they'll need to logout if they don't want their account connected on the Squeezebox after they're done. Also, the user switching doesn't seem to work quite yet. It'd be great if we could see that in action, as another requirement is that you can only have one active session on the device at a time. That is, if I switch to another Facebook account, the current Facebook account's session must be expired. Also, that means that each time you switch Facebook accounts, you'll need to enter a password. As for your question about getting extended permissions, you don't have to show the user a dialog on the device in this case but you should only get the extended permission when it's first required (that is, not all up front). So you can get "read_stream" when the user clicks on "News Feed" for the first time and you can get "publish_stream" when the user clicks on the story they want to share under "Share this on Facebook" the first time."
This is a bit ridiculous, these are huge changes at the last minute.
Understood. Please understand that I'm passing back their feedback as _soon_ as I'm getting it. Also, FWIW, while I'm a big fan of the refactoring work that was done to support multiple accounts for all relevant SB apps, multiple account support is not an absolute requirement for the FB app. The behavior around that is definitely their big issue. I'm pretty sure they don't _really_ care all that much re when we make the calls to get the different extended rights , etc. (or, at a minimum, I can get them to agree that it's fine to get these up front for our launch and until we have a follow up release).
Question for you Andy re FB sessions... What happens today if a user has two FB accounts linked to their SB and they switch to the second account BUT, before they switch to it, they go to FB.com and change the password for that account? If I'm not mistaken, in this case FB will invalidate the session we have for that user, right? If so, what do we show on the SB UI in this case?
When you link an account, we store the infinite session. However, changing your FB password kills this session. I handle this with a special error message: "Your Facebook session is no longer valid. Please re-enter your account information."
So, based on the feedback we got from FB re asking for users to login when switching accounts, how difficult would it be to just re-use this "expired session" experience in the "switch user" case? The difference here would be that, instead of having FB kill the session for the account due to a password change, _we_ would kill the session(s) for all linked accounts that are not the "active" one. Then, when the user decides to switch to a different/non-active account, we present them with this same message. Ideally it might use slightly different language, although technically the language you are already using would be accurate. I have a call with FB in half an hour and will be pushing back on this (i.e., I'll be asking them to allow us to launch "as is" and allow us to address this and other issues post-launch). But I wanted to see what might be possible and also (hopefully) low-risk since we're already doing part of this today.
Don't you think this is going to create a bad user experience?
I think there's two sides to it. On the one hand, it helps to "protect" a user from having someone else in their house post things (imagine a house with a few SBs and two siblings). In this respect, it helps the experience and makes it more like the FB website. On the other hand, it is clearly a hurdle that a user has to jump through, which hurts the experience in some ways. Like I said, I am going to ask that we be allowed to go out with the app "as is" for launch and then tackle this in a more comprehensive way later. But I wanted to understand what we're doing today re the similar case of an expired session due to a FB password change and what it would take to repurpose that to accomodate FB's request that we address this.
Just got off the phone with FB. They are still saying that they only want to see us keeping one active session at a time and require users to authenticate when switching accounts. It is OK to only require them to enter their FB password (i.e., even though in general FB doesn't like partners to cache FB users' e-mail address we can do so in this case). I told them I'd follow up internally to see if we can do this. I also told him to find out, in the case we are _not_ able to implement this before next Monday, if we should pull the Facebook app from the device. He is going to ask and get back to me later today. So, depending on their answer, we also need to be asking if this is something that is risky/complicated enough that we would be willing to launch the product with _no_ Facebook support over. :-( On a separate note, he mentioned something else they saw that he _thought_ he'd e-mailed me about (but hadn't). He said you can add a new FB account from the device without ever needing to enter your Squeezebox password. But that if you try to remove an account (or maybe it was if you try to remove the entire FB app) you must enter your Squeezebox password first. I'm sure we did this so a guest couldn't just uninstall all your stuff. However, the issue they raised is that this means a guest could enter their FB account info, but they couldn't remove it (without knowing your Squeezebox password), potentially leaving their account "stranded" on your device.
I think the safest change here would be to only support 1 FB account. We need to design a different menu structure to get what they want, I can't come up with one right now off the top of my head, and it's probably too risky. Their last point about entering your MySB account, I don't care. I'm not changing that for the reason you mentioned.
OK. How difficult and/or risky is it to implement "only one account" for Facebook since it presumably uses the same code that all the other authenticated apps uses? Also, he is still finding out just how "required" this change really is, but he has asked if we can give him a date by which we would add the only-one-active-session/require-login-when-switching-accounts functionality if they don't require it for launch/we don't get it in for launch. Pat, do we have a date for 7.4.1 at this time? Or for 7.5/8.0/whatever we're calling the Fab4 release?
It won't be too hard, the system I built has a configuration option for single-account services. Reopening and assigning to you to let me know what to do.
Andy, one related question... Today there is an on-device menu under My Apps/Facebook/Account:<username>/ that has the following options: Add new account > Remove: <username> > Once we move FB to only support one FB account, what will be displayed on the SB device UI re "account"? Will it just be a non-navigable menu item at the bottom of the FB home menu that says who the user is (e.g., My Apps/Facebook/Account:<username>)?
The menu changes to only have a 'Remove' item.
== Auto-comment from SVN commit #7412 to the network repo by andy == == https://svn.slimdevices.com/network?view=revision&revision=7412 == Fixed bug 13175, switch Facebook to single_account mode
This bug has been marked as fixed in the 7.4.0 release version of SqueezeBox Server! * SqueezeCenter: 28672 * Squeezebox 2 and 3: 130 * Transporter: 80 * Receiver: 65 * Boom: 50 * Controller: 7790 * Radio: 7790 Please see the Release Notes for all the details: http://wiki.slimdevices.com/index.php/Release_Notes If you haven't already, please download and install the new version from http://www.logitechsqueezebox.com/support/download-squeezebox-server.html If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.