[11:23] <ccooke> so... is this channel still used, or has all traffic shifted to the mailing list now?
[11:24]  * gus_ is wondering the same since some days ago....
[11:25] <SiDi> well, not everyone in ayatana ML is idling here 24/7
[11:26] <ccooke> SiDi: please don't read any negative into my question - I'm just wondering where I should be looking mostly
[11:27] <SiDi> ccooke: i think irc is better suited for discussions
[11:27] <SiDi> but if anything important is said here it'd be good to repeat it to the ML
[11:28] <ccooke> I'd agree, but I don't see much traffic here (at least, there doesn't seem to have been any that coincides with me, which is of course Not The Same Thing.
[11:30] <SiDi> I dont see anyone speaking here either to tell you the truth :)
[11:30] <ccooke> ah, well. 
[11:31] <ccooke> I've been away for a few days - once I've caught up, I guess I should try starting a discussion here :-)
[11:31] <agateau> ccooke: lots of people from Canonical DX and Design teams are here, if you have questions, just shoot
[11:31] <ccooke> agateau: I need to get caught up first :-)
[11:55]  * MacSlow -> lunch
[19:49] <GreySim> Maybe you guys have already seen this, and dunno if you care or not, but 100 paper cuts was covered on Ars Technica. http://arstechnica.com/open-source/news/2009/06/canonical-to-boost-ubuntu-usability-by-tackling-papercuts.ars
[20:11] <tedg> GreySim: Thanks for the link.
[20:11] <tedg> I do find it funny that the comments are all about how flglx sucks....  which seems relatively unrelated :)
[20:12] <seg|ars> that's pretty common for discussion threads at Ars
[20:13] <seg|ars> they did the same thing when I posted the article about the 10-second boot time goal for 10.04
[20:13] <seg|ars> everybody wants canonical to invest in fixing their personal pet peeve. ;-)
[20:13] <tedg> seg|ars: Heh, well, we'd love too.  Just too many people with pet peeves.
[20:13] <seg|ars> yeah
[20:14] <tedg> I'd love to see the AMD drivers open as well as the nvidia ones... hope with time.
[20:14] <seg|ars> imo that's only going to happen if Linux goes mainstream. And Linux is only going to go mainstream if it's usable
[20:14] <seg|ars> so I'd argue that in the long run Canonical *is* contributing to a solution to the broader problems by focusing on usability. :-)
[20:16] <tedg> In many ways it's a chicken and the egg problem.  I'm hoping that the driver folks will change their story if we can get mainstream with OEMs, so that mass market users don't have to deal with the issues.
[20:16] <GreySim> Oh, I didn't realize seg was IN HERE. >.<
[20:16] <seg|ars> haha
[20:17] <seg|ars> GreySim: thanks for linking my article. ;-)
[20:18] <GreySim> seg|ars: Thanks for writing it. :D
[20:19] <ivanka> seg|ars, hi
[20:20] <seg|ars> hello
[20:21] <seg|ars> ivanka: this is a video of the gwibber prototype: http://segphault.cixar.com/img/screenshots/applications/utilities/gwibber/v2.0-1.ogg it provides a clearer picture of how it works
[20:21] <ivanka> new design is looking very good
[20:21] <seg|ars> thanks. :-)
[20:22] <seg|ars> there are some complex UI problems that I haven't come up with a good way to solve, like how to let the user "close" transient streams
[20:22] <ivanka> I'll check the video
[20:25] <ivanka> From the usability sessions I have some 'first use' feedback
[20:25] <seg|ars> excellent
[20:26] <ivanka> So - we were testing with people who had barely heard of linux, nevermind Ubuntu or Gwibber (just to set context)
[20:27] <ivanka> I think your 'account tree' might be a great way to get people to understand what Gwibber does
[20:28] <ivanka> especially if they can add the accounts through the tree...
[20:28] <seg|ars> at the present time, the tree is populated based on what accounts the user has configured
[20:28] <seg|ars> I wasn't going to have the tree show at all until the user set up their accounts
[20:29] <ivanka> I suspected as much :-)
[20:29] <ivanka> hear my rationale
[20:29] <ivanka> people open Gwibber 'microblogging' - is that like twitter and stuff?
[20:31] <ivanka> they go to the Gwibber menu which neither explains nor gets them started
[20:32] <ivanka> In the Accounts menu they have to scroll down before they appreciate the full range of available accounts
[20:32] <ivanka> before I saw your mockup I was toying with how to bring all those logos higher up in the nav
[20:33] <ivanka> the tree might not be the answer but it might be a quick and easy way to provide that 'at a glance - what does this do' functionality
[20:33] <seg|ars> ah I see what you are getting at
[20:34]  * ivanka keeps getting interrupted by her little sister
[20:34] <seg|ars> for the first run experience, what I was thinking about doing is having the tree not show and then having the icons in the main content area
[20:35] <seg|ars> so there would be a short introductory message and then big icons that the use can click to set up their account for several of the services
[20:35] <ivanka> would the user be able to interact with them in any way?
[20:35] <ivanka> :)
[20:35] <ivanka> lovely
[20:35] <seg|ars> and I figure that it should only show like four or six of the most popular services that gwibber supports, not all of them
[20:36] <seg|ars> because I've been hearing that some users get intimidated by the large number of services in the account creation menu
[20:36] <ivanka> that sounds right and familiar to me
[20:38] <seg|ars> and there could be a link that says "more services" or something that they could click to get the full list
[20:38] <seg|ars> the main content area in gwibber is a webkit renderer, so that provides a lot of flexibility for presentation
[20:38] <seg|ars> it's possible to do anything that can be done with a web page
[20:38] <ivanka> ah - very good 
[20:38] <tedg> It seems like that should be the default configuration dialog though. It seems like people would expect to be able to get back to the same configuration.
[20:39] <Nafallo> hmm
[20:39] <tedg> If it's a good idea, it's a good idea for every run, not just the first :)
[20:39] <seg|ars> yeah, that's a good point. Maybe it could be like a "home screen" or something
[20:39] <ivanka> I was about to say that we have to be careful how we connect this lovely first run to the Account menu
[20:39] <Nafallo> how about putting the most common ones greyed out in the tree?
[20:40] <Nafallo> and when you click them in can open a add account dialog with that service preselected.
[20:41] <ivanka> Nafallo, I was thinking that before I heard about the new and improved first run - both have merit
[20:41] <ivanka> I like the idea of a "home screen"
[20:41] <seg|ars> I think that the home screen could potentially be a complete replacement for the account management dialog
[20:41] <ivanka> yes
[20:41] <Nafallo> home screen? I didn't lurk long enough to hear about that :-)
[20:42] <ivanka> in testing we often see people anchor their behaviour to one "home screen" type thing
[20:42] <ivanka> It would be a much nice way of doing things
[20:42] <ivanka> and encourage the interaction with the content area
[20:43] <seg|ars> one aesthetic issue is that we don't have high quality and visually consistent icons for all of the services
[20:43] <ivanka> seg|ars, I am sure we can fix that
[20:43] <seg|ars> awesome
[20:43]  * tedg will make icons that will make all of the services' artists rush to replace them.
[20:44] <seg|ars> haha
[20:44] <ivanka> haha
[20:45] <Nafallo> lol
[20:46]  * Nafallo adds the trunk PPA and tries it for the first time.
[20:46] <ivanka> seg|ars, on a slightly different note
[20:46] <Nafallo> facebook doesn't co-op with me wanting to try it :-(
[20:47] <ivanka> Have you done anything with the 'sending' text box thingy (technical term)
[20:47] <seg|ars> Nafallo: facebook made some changes that broke the version in the jaunty repository. I haven't had a chance to backport the new facebook stuff yet
[20:48] <seg|ars> ivanka: a gwibber contributor made a new sending textbox that is resizable and has a few other improvements
[20:48] <Nafallo> seg|ars: that explains it. 404 and 503 all over the place :-)
[20:48] <seg|ars> ivanka: the new input textbox is resizable and it will let you exceed the max character count but will turn red when you do
[20:49] <seg|ars> I'm working on configuring it so there can be a different max character count for each service
[20:49] <ivanka> seg|ars, cool - does it have feedback for 'I am sending this message, all is well'
[20:49] <seg|ars> not yet
[20:49] <seg|ars> do you have some ideas for that?
[20:49] <ivanka> I have some ideas for what wouldn't work 
[20:50] <ivanka> it can be useful to get them out of the way, I find
[20:50] <seg|ars> yeah
[20:50] <seg|ars> the other issue that needs to be addressed is that it needs to be clearer which services the outgoing messages are going to
[20:51] <ivanka> Something as simple as hiding the text
[20:51] <ivanka> yes
[20:52] <seg|ars> have you ever tried right-clicking the input textbox?
[20:52] <seg|ars> there are checkbox items on the context menu for toggling which services it sends to
[20:52] <seg|ars> that feature generally lacks discoverability. A lot of users don't know that it exists
[20:53] <seg|ars> one approach that we have considered in the past is having a toolbar with toggle buttons for each service
[20:53] <ivanka> we have been thinking about this a bit too - in a different context
[20:54] <ivanka> do you think toggle buttons with the logo below the text box would work?
[20:54] <ivanka> Type in your message
[20:54] <ivanka> hit the twitter button
[20:54] <ivanka> then the Facebook button
[20:54] <seg|ars> yeah
[20:54] <ivanka> or the 'all' button
[20:54] <seg|ars> another approach that I'm considering right now is that when you have an account selected and you are looking at a filtered stream in the tree, it will send messages to only that account
[20:55] <GreySim> What about user-configurable groups with a dropdown to pick "All", just a single services, or a configured group? "Status Updates" ...or...I can't figure out other possible groups, but I'm just trying to throw out ideas.
[20:55] <seg|ars> so I think that I'd do it that way when the user has selected one of those streams, and then have the toolbar at the bottom when the user is viewing the "all messages" stream
[20:55] <seg|ars> GreySim: I like the idea of groups, but I think it creates too much complexity
[20:55] <seg|ars> GreySim: like the way that pidgin handles custom statuses, it's just too confusing to end users
[20:56] <ivanka> Remember that more people don't customise than do
[20:57] <ivanka> seg|ars, I think the filtered tree stream should also work
[20:58] <seg|ars> yeah
[20:58] <seg|ars> I'm trying hard to make sure that the tree is completely optional and that the UI isn't too dependent on it
[20:58] <seg|ars> because I think that some users might object to how much extra screen space it uses
[20:59] <ivanka> you make a valid point
[21:00] <ivanka> seg|ars, phone is ringing - please excuse me
[21:16] <lamalex> tedg: ping
[21:16] <tedg> lamalex: Hello.
[21:17] <lamalex> tedg: how did you guys get around the indicator applet taking up space when no apps were running?
[21:18] <tedg> lamalex: Secrets :)
[21:18] <tedg> lamalex: Basically by lots of gtkrc magic.  If you look at indicator-applet you can see a large amount of GTK style strings being loaded.
[21:19] <tedg> lamalex: Basically those take away all the buffering and backgrounding that normally is associated with GtkMenu and GtkMenuItem.
[21:19] <lamalex> ah
[21:19] <tedg> lamalex: If you want to do that, I'd just steal that code.
[21:19] <lamalex> sucks that gtk makes you do all of that
[21:19] <lamalex> yah, i think im going to ;)
[22:04]  * Nafallo ponders why indicator-applet refuse to work on his system