?

Log in

No account? Create an account
entries friends calendar profile Previous Previous Next Next
Jef"I am the pusher robot"Spaleta
ramblings of the self-elected Fedora party whip
jspaleta
jspaleta
Mumbles and Notifications
So Shuttleworth has written up a non-technical blog about new notifications experiment that Canonical is championing.

The video he links to in his blog is a mockup of the interaction. Is there any existing codebase for any of this work? It looks pretty similar to the mumbles project which already has packages out for Ubuntu users to play with. Has anyone in Canonical's User Experience Design or Desktop Experience teams talked with the mumbles project? I'd hate to think that Canonical was unnecessarily doing in-house, closed-door work that was already being done by the wider Ubuntu community in an open development manner.

While its surprising that Canonical was out of touch with the community initiatives already going out out there and wasn't aware of the mumbles project, I'm sure it was just an oversight on their part. Basic background research into existing projects is an easy thing to skip doing. I'm sure they weren't planning on doing something like forking the mumbles project codebase and enhancing it without communicating with the mumbles developers about their plans. Canonical would never do that sort of patching and enhancing on an existing project without informing upstream developers first about what they were doing. Would they?

But man mumbles existing implementation looks so much like that Canonical mock up. Maybe they really did just develop it with inspiration from the OSX growl application like the mumbles developer did. Except Shuttleworth doesn't mention growl either as an inspirational comparison.

Shuttleworth also mentions something at the end of his blog about putting binaries out for testing in conjunction with an OEM partner shipping a product with this notification feature. Hmm, I'm pretty sure the Ubuntu Code of Conduct mentions something about being collaborative and sharing your code publicly before you release it in a product. From my reading of the very Code of Conduct that Shuttleworth would hold the external Ubuntu community to, I would have thought waiting on an OEM partner's product release to put things out for testing would be discouraged under the Code of Conduct as written.

I hope the last paragraph in Shuttleworth's blog is some sort of misstatement and that Canonical is planning on living up to its own community's Code of Conduct concerning collaboration by releasing the notification daemon codebase for testing well before it shows up in any OEM product offering.
4 comments or Leave a comment
Comments
From: (Anonymous) Date: December 23rd, 2008 01:14 pm (UTC) (Link)

Looks like mumbles, acts different

Your making the common mistake of focusing on how they look. The problem with notifications is not how they look but how they work. There are several notification mock-ups/implementations that look alike, it's surprising that someone with your experience would make this mistake.

Anyway, in Mark's blog, he says:
- it's an experiment that *could* gain no traction but will hopefully move notifications along
- it's based on a subset of the freedesktop.org specification and will be largely compatible with libnotify
- they sought contributions from K/Ubuntu, Gnome, KDE and Mozilla camps
- it will be first tested in a OEM-shipped netbook environment before wider code release

The K/X/Ubuntu community share your concerns about the last point and we'll see what happens. Mark tends to make bold, well-intentioned moves that serve multiple purposes. He gets cut some slack because he has a history of doing the right thing and listens to dissenting opinions. It is also not entirely his decision to make, despite being "sabdfl", so let's just wait and see. It will likely come down to a matter of timing; ie. how soon a working implementation can be developed.

- Edward -
jspaleta From: jspaleta Date: December 23rd, 2008 04:59 pm (UTC) (Link)

Re: Looks like mumbles, acts different

The video is a mock up... its all about how it "looks". Is there any existing public code for the Canonical approach or not at this moment in time? It's nice to talk about the code, its far more "collaborative" to make the code available to look at. Prove me wrong, find the code, show me the code.

Here's the point. Mumbles has been an "experiment" for over a year. Its been talked about in the Ubuntuforums.. it has an entry in brainstorm and been voted up. Has anyone from Canonical talked to the Mumbles dev at all in that year+ timespan over which Mumbles has been developed in the wider community? How do you know that the Mumbles dev wouldn't be open to Canonical's ideas? It's an existing codebase, not a mockup, and that should count for a hell of a lot, at least a developer level conversation about future roadmaps. How respectful is it for Canonical to go off and do their own interpretation on notifications without at least a head nod to the existing experiments in the same space in the Ubuntu community. Not-Invented-Here symdrome at its finest.

The Ubuntu Code of Conduct makes being "collaborative" an important concept. Is it really in the community's best interest to cut Canonical slack with regard to adhering to that Code of Conduct? It's a slippery slope, and by doing that you are complicit in fostering a corporate culture inside Canonical which is in direct conflict with the idea that open development is the right way to do things. If you don't demand Canonical keep its nose clean and do things the right way, then other business forces outside of the community's control will put pressure on them to do it the more traditional way. I'm not telling to hold grudges against them for past bad behaviour, that's my job, but I am telling you to publicly stand firm and politely demand the code be released for this experiment as part of the code development process, before the OEM product ships, as obligated by the Ubuntu Code of Conduct. It is in your best interest to hold them to the conduct standard.

This OEM partnership stuff is just one example. You don't have access to those business level conversations, so you don't know what sort of agreements Canonical and the OEMs are making behind closed doors. There is no transparency. But what you do have access to is that Code of Conduct statement, which is Canonical's agreement to the community to do things the 'right' way. I seriously doubt Canonical would back out of an OEM agreement without risking that partnership relationship with the OEM, but that is exactly what they are doing to the community by not living up to the tenants of the Code of Conduct. It's not in your best interest to cut them slack. Its in your best interest to have them be an upstanding corporate citizen of your community, living up to the community standards they set down.

-jef
From: (Anonymous) Date: December 24th, 2008 03:43 am (UTC) (Link)

Re: Looks like mumbles, acts different

Once again, "The difficulty with notifications is not how the look but how they work". The important results of the UDS discussions were not about anti-aliasing and alpha-blending, don't focus on the video. The important issues were:
- notifications must not demand/require action
- they should be asynchronous and potentially queued (on the display side, see Mark's blog)
- compatibility with libnotify and support for the most common use cases

Regarding mumbles, libnotify support is something that was intentionally left out (though there has been talk of adding support in the future). The developer had his reasons (which are only slightly at odds with the UDS proposal) but that is a path Canonical and Ubuntu could not follow. At least not before establishing common ground with all parties on API, DBus namespace and backwards compatibility. Working with several desktop environments and multitudes of applications inevitably means there will be misunderstandings and ill-tempered words. So far they have been minimal and/or quickly resolved. To paraphrase Mark, it is going to be more a matter of conversation than code.

I don't wish to comment further on the OEM issue, as you point out, it is potentially covered by a business agreement. Canonical can give you a more complete answer on that, if you ask them nicely.

- Edward -

PS: The Code of Conduct does not say what you think it says. The difference however does not advance our current discussion.
jspaleta From: jspaleta Date: December 23rd, 2008 06:10 pm (UTC) (Link)

Re: Looks like mumbles, acts different

about Canonical seeking out KDE collaboration...

http://aseigo.blogspot.com/2008/12/free-dektop-notifications.html

"I was a disappointed that I had to find out from someone who happened to be at the event that this was going on, however. This is the kind of work that belongs on the xdg list from the very start with all the stakeholders. Far too often well meaning downstreams head off and start implementing things so excited and enthused about what they are doing that they don't lift up their head and look around at who else is being effected, or should be effected, by their efforts. I know that working with others is harder than working by yourself and that making a coherent experience is not the easiest path. It is, however, the best path."
4 comments or Leave a comment