[12:59] <wers> hello
[13:00] <thorwil> word
[13:00] <JanCBorchardt> +1
[13:00] <JanCBorchardt> vish is lurking as well :)
[13:01] <wers> where's our leader?
[13:01] <wers> I'd like to discuss something organizational today
[13:01] <thorwil> that might be just vish's being present everywhere, though
[13:01] <wers> vish is omnipresent
[13:06] <JanCBorchardt> do I remember correctly aday saying that he can not attend today?
[13:06] <wers> I dunno..
[13:12] <JanCBorchardt> so … do we just start then or can someone poke mpt?
[13:14]  * vish not here.. on the way out :)
[13:15] <thorwil> wers: what's the organizational something?
[13:15] <wers> thorwil, just thought that we can review ayatana ux's goals
[13:15] <wers> what are we here for and are we successful so far?
[13:16] <wers> look at the description here https://launchpad.net/~ayatana-ux
[13:16] <wers> "This team will coordinate activities like persona generation, distributed user testing, heuristic evaluations, publishing and promoting design guidelines, and collection of ideas from Brainstorm, forums and elsewhere."
[13:16] <wers> do we do any of those?
[13:17] <thorwil> heh, no
[13:17] <JanCBorchardt> wers, I briefly thought about that too when I joined ;)
[13:17] <wers> should we review our goals?
[13:17] <godbyk> have we done much of anything?
[13:17] <wers> if not, what should we do?
[13:18] <wers> I hope, mpt was here
[13:19] <JanCBorchardt> well about the ideas from Brainstorm and forums thing: Brainstorm is actually a big pile of what users want, we could catalyze that.
[13:21] <JanCBorchardt> like homework for everyone: Find 2 Brainstorm ideas that ideally bug yourself and would improve user experience greatly. Then we can put them together and decide on one or two. Similar to the paper cut project except it may not be an easy solution
[13:25] <wers> the thing about homeworks like that is, people rarely do em... contributors do what they feel like doing
[13:27] <JanCBorchardt> yep, but then why do we have the team? ;)
[13:28] <thorwil> is anyone of us working on anything that is specific to ubuntu/ayatana?
[13:29] <wers> JanCBorchardt, good question. I just observed this trend in a project like UX Advocates. only the advocates of 4 pieces of software participated
[13:29] <wers> thorwil, I think, the scope of Ayatana isn't even well-defined
[13:30] <wers> and this group turned into a subset of GNOME design
[13:31] <wers> I'm not saying that it's a bad thing. I just think that we have to rethink our goals, what we actually do, and how we do things
[13:31] <wers> we don't have success metrics. we just discuss random design-related things every week
[13:31] <thorwil> my motivation usually comes from getting a portfolio piece out of it, seeing a solution being realized and simply working on interesting concepts (this last one hasn't worked that well, lately)
[13:32] <thorwil> so unsurprisingly, this here doesn't work. the whole ayatana wiki and ml doesn't work for me
[13:33] <wers> thorwil, what  portfolio piece?
[13:33] <JanCBorchardt> thorwil, I have found the Ayatana ML to be quite inefficient as well.
[13:34] <thorwil> if a saw the chance of helping to build some infrastructure or documentation that will really make a difference, that would work for motivation, too
[13:34] <JanCBorchardt> I thought that’s why this team existed. To channel UX activities in Ubuntu.
[13:35] <wers> JanCBorchardt, as far as I understand, Ayatana UX was formed to be like Ayatana's core team
[13:36] <wers> this sub-org should lead the org (ayatana)
[13:36] <wers> is my understanding correct, thorwil ?
[13:36] <thorwil> wers: portfolio piece == example of my work that i can show to potential clients or employers
[13:36] <wers> thorwil, ooh. ok
[13:38] <thorwil> the ideal case is a design being implemented that helps me, being a showcase, and that helps all the users, because it solves a problem and that makes developers happy because they had something nice and worthy to implement
[13:39] <thorwil> so far this only really worked with ardour
[13:40] <wers> thorwil, if it always worked out, our work here would be a lot more sustainable and rewarding
[13:40] <wers> what ways do you suggest to resolve this?
[13:40] <thorwil> if only i had an answer ...
[13:41] <wers> I feel that we exchange so many ideas that don't get materialized in the end
[13:41] <thorwil> one crucial component is direct contact to a developer
[13:41] <wers> some are really great, but it's a shame they don't get coded
[13:41] <thorwil> often you need just one developer, but if he isn't the project leader, the leader must be on board, too
[13:42] <wers> hmm
[13:42] <wers> so it would help if ayatana ux had dev contacts, right?
[13:42] <JanCBorchardt> wers, yes
[13:42] <thorwil> i think that might be at the core of what makes it so hard to get anything happen in gnome or ubuntu
[13:42] <wers> the thing about volunteer work is, you really just do it if you believe in the project. our devs should buy UX too
[13:43] <wers> thorwil, what do you mean?
[13:43] <JanCBorchardt> wers, that you need (to be) a dev to get anything done
[13:43] <thorwil> wers: clear leadership and the direct contact to it
[13:43] <godbyk> How to developers and designers work together now?  Or do they?
[13:43] <wers> a good example is the usability testing lab. it's great that JanCBorchardt codes. if not, the project would've rotten
[13:44] <wers> ok. I think, we're on the right track now. this sort of discussion should've occurred long ago
[13:45] <thorwil> yes. i think i should pick up coding, if i want to see more things happen. but that's not a skill i will earn money with any time soon ...
[13:45] <JanCBorchardt> wers, and it’s also great that someone is helping me because I’m having a busy time. Also, the kazam screencasting tool is on the way.
[13:45] <wers> JanCBorchardt, who else does the coding for those?
[13:46] <JanCBorchardt> for Pongo or Kazam?
[13:46] <wers> thorwil, that's the issue.. +1 here.
[13:46] <wers> JanCBorchardt, both
[13:46] <thorwil> godbyk: you sometimes have developers asking for assistance in design matters and that's a way how it can work fine. except it's often about details, then. can't tackle the grand concepts that way
[13:47] <wers> I wonder how you make those happen
[13:47] <godbyk> thorwil: that's what I've noticed.  by the time the developers approach the designers, it's too late to have a big impact.
[13:47] <JanCBorchardt> Kazam is done by and471 (Andrew Higginson) and pm-netzor (Peter, Launchpad) is helping me with the Pongo GUI
[13:47] <wers> godbyk, thorwil is right. it's probably because volunteers work on the things they have ownership on
[13:48] <wers> we can't just plan here and convince coders that this is the right way. we have to either be so charismatic, pay money, or include them in the thinking process
[13:48] <JanCBorchardt> gnome-design does that pretty good. Always healthy conversation with developers.
[13:48] <godbyk> something I proposed to mpt a while back was to have a website/book/single resource that pulls together design principles and how they apply to open source projects.  a place where developers could learn about how to do better design themselves.
[13:48] <JanCBorchardt> godbyk, sounds like the UX pattern library
[13:49] <JanCBorchardt> aka GNOME HIG 3.0
[13:49] <godbyk> JanCBorchardt: yeah, along those lines, but a bit grander in scope.
[13:49] <wers> perhaps, we need a (or some) dev(s) and/or PM(s) on board
[13:49] <wers> JanCBorchardt, didn't know someone's already working on coding the GUI. good job!
[13:50] <wers> JanCBorchardt, how do you get them involved?
[13:50] <godbyk> JanCBorchardt: instead of just a collection of patterns, I think it'd be useful to explain some of the underlying principles behind UI design.
[13:50] <JanCBorchardt> wers, I tipped off omgubuntu and webupd8, that got it rolling.
[13:51] <godbyk> and those sorts of principles apply to more than just gnome, linux, etc.
[13:51] <wers> JanCBorchardt, great. this is really about people skills
[13:51] <JanCBorchardt> godbyk, like ideologies, not only solutions?
[13:51] <wers> godbyk, sounds like a UX bible
[13:51] <godbyk> something like that. :)
[13:52] <wers> I've this long term plan of institutionalizing UX in FOSS. that way, the whole process will follow UCD
[13:52] <wers> with the influence of JJG's Elements of UX http://www.adaptivepath.com/events/workshops/businessofux/elements0803.pdf
[13:52] <godbyk> wers: yes, I think we definitely need to move toward that.
[13:52] <wers> but that's so grand. I need help in defining the specifics
[13:53] <thorwil> i have this dream of a website that assists people in following certain design methods and to do heuristic evaluations along the way
[13:54] <godbyk> does this type of 'big thinking' seem like something that the ayatana ux team should be about?
[13:54] <thorwil> if projects just had good briefings and kept them in mind, a lot would be won
[13:54] <wers> JanCBorchardt, btw, I haven't mentioned this to you yet. the name of the Usability lab has "Suite" on it on the wiki. someone suggested turning into a one-stop-shop kind of thing. with tools for personas and other stuff for UCD
[13:55] <godbyk> thorwil: agreed.
[13:55] <wers> godbyk, I think, we should re-evaluate our organizational goals and this new direction seems to be ideal
[13:55] <thorwil> godbyk: yes and no. everything not actionable is worthless. a distant goal that shows the direction for actual steps is good. but if no steps are taken, it's all useless
[13:55] <JanCBorchardt> wers, yes, it’s really not about the one tool but about techniques how to do user testing
[13:55] <JanCBorchardt> wers, Pongo is only a small part of it
[13:55] <mgunes> godbyk, increasing the mindshare of design and ux among foss contributors and fans should definitely be one thing ayatana-ux should be about
[13:56] <mgunes> that's a goal worth striving for
[13:56] <godbyk> thorwil: true. but does this seem like the direction we should go in? if so, we can define concrete goals and outcomes.
[13:56] <wers> JanCBorchardt, that's right. in the future, let's turn it into a UX suite
[13:56] <wers> I wonder how Mairin's design hub is going
[13:56] <wers> mgunes, that's a really great goal. let's find ways to do that
[13:57] <godbyk> I'll gather up my notes on the idea I proposed to mpt and send an email to the ayatana ux mailing list.
[13:57] <mgunes> could we extend this discussion to the mailing list and spread it over the next week or so? I've been meaning to start it myself.
[13:58] <wers> I'd like to start this long term "Institutionalizing UX" project
[13:58] <wers> mgunes, let us
[13:58] <mgunes> godbyk, that would be appreciated
[13:58]  * wers thinks this is our most productive meeting so far
[13:59] <wers> we've been hacking the leaves of evil, but we haven't been striking the root
[13:59] <thorwil> can we agree on that there should ideally be a scheme that many floss projects will follow, that includes that there's consistent documentation about the project briefing, design considerations, concepts, decisions?
[13:59] <thorwil> which can happen on the websites of the projects, or on centralized platforms?
[13:59] <godbyk> thorwil: you mean to define a format for a project outline/brief?
[14:00] <wers> thorwil, we need a common platform for that
[14:00] <wers> for example, launchpad
[14:00] <wers> tweaking launchpad to accommodate that would be great
[14:00] <godbyk> I don't think it *requires* a platform, but some good examples and a template wouldn't be amiss.
[14:01] <wers> godbyk, with a common platform, ways could be standardized and things are tracked more easily
[14:01] <godbyk> something that simply causes a developer starting a new project to take a moment to consider ux would be good.
[14:01] <JanCBorchardt> I recently talked with Peter Sikking (of GIMP) about exactly that: the need for clearly documenting and communicating design decisions
[14:01] <thorwil> to be clear, it's a huge goal, but we could split it into parts that will be beneficial to have, anyway
[14:01] <godbyk> wers: sure. I'm all for a platform, but I don't think we need to wait for one to be built before we start.
[14:01] <wers> godbyk, but yeah, it really doesn't *require* one. let's start simple
[14:01] <wers> at least, we started
[14:01] <mgunes> just throwing this out there: maybe a "free software ux manifesto" similar to the Agile manifesto could help
[14:01] <thorwil> yes
[14:02] <godbyk> mgunes: that'd be cool.
[14:02] <wers> mgunes, can you expound? I'm not familiar with the Agile manifesto
[14:02] <mgunes> it would just be a statement that a project undersigns, as a statement of intention, which would expand the mindshare
[14:02] <thorwil> the core should be the most central goals of UXD, from which everything else follows
[14:02] <JanCBorchardt> wers, http://agilemanifesto.org/
[14:02] <thorwil> with just enough insights from cognitive psychology to have a solid base
[14:03] <mgunes> wers, the thing about the Agile manifesto is that while it's a strong (and for its time, radical) statement of vision, it's essentially non-binding
[14:03] <wers> ooh
[14:03] <wers> that would be great
[14:03] <JanCBorchardt> but it clarifies the ideology, and that’s an important start
[14:03] <mgunes> right
[14:04] <thorwil> though this is a killer when applied to what we are discussin ghere: we value "Individuals and interactions over processes and tools" ;)
[14:04] <wers> too bad I have to go. I'll try to go online with my mobile while on the road
[14:04] <mgunes> a similar ux manifesto could be a sort of "badge" that projects use to indicate that they care about ux and involve ux principles in their development
[14:05] <mgunes> wers, goodbye
[14:05] <mgunes> I have to depart as well; I'll definitely check the log, and *please*, let's continue this on the mailing list.
[14:05] <JanCBorchardt> mgunes, and a benchmark they can use when needing to make interface or interaction decisions
[14:06] <mgunes> JanCBorchardt, Nielsen's heuristics or something similar could be useful as such a general benchmark
[14:07] <godbyk> mgunes: I've got a book that has a bunch of principles in it that I like. I'll just them to the mailing list for discussion.
[14:07] <godbyk> (Actually, I have a handful of books that list a bunch of principles.  I'll see if I can compile some of those lists for comparison.)
[14:07] <mgunes> godbyk, please do
[14:08] <godbyk> some of it may have to wait 'til the weekend, but I'll make a note so I don't forget.
[14:08] <JanCBorchardt> do you know about the Mozilla UX tags for Bugzilla?
[14:09] <godbyk> I eavesdropped on that session at UDS-M.
[14:09] <JanCBorchardt> here it is: https://blueprints.edge.launchpad.net/ubuntu/+spec/design-m-heuristics-and-bugs
[14:10] <JanCBorchardt> and aren’t these the most central goals of UXD?
[14:11] <JanCBorchardt> they should not only be applied as an afterwards measure (tagging bugs) but as principles, guidelines for new apps and benchmark for decisions
[14:12]  * thorwil -> coffee
[14:14]  * vish catches up with logs..
[14:15] <vish> JanCBorchardt:  kazam was andrew idea for a very long time.. but he just got around to finish it..
[14:16] <vish> had had school , and SC coding that kept distracting him..
[14:16] <vish> *he had
[14:17] <JanCBorchardt> vish, yep, I’m glad it is rolling now :) I was talking to him about collaborating but screencasting and usability testing asks for quite differently shaped tools ;)
[14:18] <wers-android> Jancborchardt i like how social media worked for that purpose
[14:18] <vish> godbyk: i think we are going about this the wrong way.. not we cannot be 'thinking big' yet.. and JanCBorchardt's assessment about gnome-design being effective is an illusion ;)
[14:19] <JanCBorchardt> vish, explain :)
[14:19] <godbyk> vish: how should we be going about it, do you think?
[14:19] <vish> the only reason gnome-design is being effective is because they already were already *in* discussion and several of them are already part of those upstreams..
[14:20] <JanCBorchardt> vish, that’s what I mean ;)
[14:20] <godbyk> effective at what? and in discussion about what?
[14:20] <vish> effective at getting quicker design approvals
[14:21] <vish> we should rather , find out which areas need help and attack those areas , rather than throw random ideas around..
[14:21] <JanCBorchardt> vish, did you read the complete backlog?
[14:21] <vish> oh! no :)
[14:21] <JanCBorchardt> vish, ;)
[14:21] <godbyk> vish: Ah, I'm more interested in tackling the larger, overall problem of lack of UX design/thinking when software is being written.
[14:22] <vish>  i stopped here!  ;p <JanCBorchardt> gnome-design does that pretty good. Always healthy conversation with developers.
[14:22] <JanCBorchardt> vish, then continue, it gets better :)
[14:22] <JanCBorchardt> so, does someone already have the log?
[14:22] <wers-android> vish, what's the illusion thing about?
[14:22] <vish> ok , but that was an illusion , just wanted to mention that..
[14:22] <godbyk> Specific problems should, of course, be tackled and solved. But I think we should work to shift the culture a bit from one of people jumping into writing code to one that takes a more design-minded approach first.
[14:23] <vish> wers-android: the only reason they are effective is because they several are already part of redhat..
[14:24] <vish> or friends from before..
[14:24]  * vish continues readin..
[14:24] <JanCBorchardt> godbyk, ideally those things happen parallel. That’s what I meant with gnome-design being effective in my eyes. They have mockups and discuss with the devs, they code it and come to get feedback. Iteratively.
[14:25] <JanCBorchardt> vish, yep, I know they have a massive advantage. But that does not make them being effective an illusion. ;)
[14:26] <vish> JanCBorchardt: well , the "does that pretty good" is the illusion ;)
[14:26] <wers-android> i think, it's a big thing that mccann codes. code talks
[14:27] <wers-android> don't they do it well?
[14:27] <wers-android> anyway, let's focus on the solution for us
[14:27] <wers-android> not on other's success or failure
[14:28] <JanCBorchardt> wers-android, yep, UX principles are nice but we need to actually have them applied. The problem is not in writing them down but communicating them to the people who code. Just what mgunes said: » increasing the mindshare of design and ux among foss contributors and fans«
[14:32] <godbyk> bbiab
[14:32] <thorwil> JanCBorchardt: i have logging turned on
[14:43] <vish> ok.. IMO , discussing anything here is not going to change anything in gnome upstream.. :)
[14:44] <vish> we should rather discuss about ayatana changes , any problems we identified or how we can improve them
[14:44] <vish> And godbyk's idea of a book though it sounds great[from what i understand] , but
[14:45] <vish> .. i have a hard time believing that any gnome project would adopt it. or open source project..
[14:45] <vish>  IMO , it would be a huge investment of time with very little rewards.
[14:45] <vish> we can aim for something like agilemanifesto , but if its about making it a binding tool , then it would be very tough
[14:46] <JanCBorchardt_> vish, promoting the ux heuristics and making more projects aware of them sounds like a good start
[14:48] <vish> JanCBorchardt_: yup.. i *really* like the idea for the book.. but i'm not confident of it being adopted..
[14:49] <JanCBorchardt_> vish, important for adoption is the same common ground. And Mozilla is already working with those heuristics as bug tags
[14:50] <vish> JanCBorchardt_: yup, which projects are interested in that right now?
[14:51] <vish> JanCBorchardt_: i'm just playing the devil's advocate :)   .. there is gnome3 HIG in the making, wouldnt it be more worth spending time in that?.. just a time <-> effective output ratio
[14:52] <JanCBorchardt_> vish, GNOME3 HIG is very specific, implementation details. The UX-heuristics are groundwork for that (like one pattern adheres to several heuristics). Also, they are already there.
[14:52] <JanCBorchardt_> vish, not really groundwork, but rather background / ideology
[14:52] <vish> ah!
[14:54] <mgunes> see also: https://blueprints.launchpad.net/ubuntu/+spec/design-m-heuristics-and-bugs
[14:54] <vish> yeah , i'v seen that..
[14:58] <vish> mgunes: why it worked for FF is the design team tried to work for a problem they had to address , tag relevant bugs and then look at it for final designs..
[14:58] <vish> where do we want such tagging to be used?
[14:59] <mgunes> that's a question I had asked in a previous meeting
[14:59] <mgunes> my answer is: user-facing packages for which Ubuntu / Canonical is an upstream, and default desktop components. that's a start, if not an ambitious one
[15:00] <vish> exactly! so ayatana issues.. :)
[15:00] <mgunes> largely, yes
[15:00] <vish> thats what i said earlier.. if its throughout gnome, then its no point in us discussing it here , we should work with gnome regarding those
[15:01] <mgunes> agreed
[15:03] <vish> my understanding of why mpt formed this team was : ayatana ML became a mess, [thorwil had too many friends on the list ;p ] , mpt wanted help regarding some of the issue he would like to address, so he identified a few people who would not drive him too crazy and formed this list to be more a more effective ayatana discussion
[15:03] <vish>  be *a more
[15:06] <mgunes> I view this team mostly as the community counterpart of the Canonical design team. Every Ubuntu-related team that Canonical employs has such a counterpart, or integrates community contributors directly; the design team didn't, and it was seen how that was and would continue to be a problem after the "window buttons on the left" saga.
[15:07] <godbyk> back.
[15:11] <godbyk> vish, mgunes: I think you're both right about why the team was formed.
[15:11] <godbyk> vish: wrt the book idea: my train of thought that led me to it was this:
[15:12]  * mgunes catches up on the log
[15:12] <godbyk> I think we'd like designers to be involved in the application design far sooner than they are.  It's often too late to have an impact on the UX design by the time bugs are being filed.
[15:13] <godbyk> There aren't enough designers to help all the developers with all their projects.
[15:13] <godbyk> Additionally, I don't want it to seem like developers should/must consult with a designer oracle before starting work on their project.
[15:14] <godbyk> I would like to see the projects better designed from the start, however, and the design-thinking should persist through the entire life of the project.
[15:14] <vish> godbyk: isnt that what the HIG does?
[15:14] <godbyk> So it seems that our best hope is to get developers on board with some design principles so they don't need designers to hold their hand the entire time.
[15:14] <vish> gives the developers something to refer to?
[15:14] <godbyk> vish: The HIG is entirely too limited in scope.
[15:15] <godbyk> The solution I thought of was to provide resources that developers can use to learn how to better design the UX of their software.
[15:15] <vish> godbyk: maybe we should expand it then?  i would expect _that_ to be a reference more of a  tool
[15:15] <godbyk> Hence the book.
[15:16] <vish> godbyk: seriously , i'm not trying to discourage you :)
[15:16] <godbyk> vish: The HIG only applies to GNOME and (at least with HIG 2) was focused more on the nuts and bolts of conforming to a visual style with a few bigger design notions tossed in for kicks.
[15:16] <godbyk> vish: No, no. I understand completely.  :)
[15:17] <vish> phew.. :)
[15:17] <godbyk> vish: And it may be that the HIG (or some meta-HIG) could be devised that would take on this role.  I'm cool with that.
[15:17] <vish> godbyk: for app everywhere? gnome/KDE/XFCE?
[15:18] <godbyk> vish: The general design principles would apply to apps under GNOME, KDE, XFCE, etc., yeah.
[15:18] <godbyk> And cross-distribution.
[15:18] <JanCBorchardt_> godbyk, so something more abstract that the ux-heuristics?
[15:18] <godbyk> It's not about 'how do I make a nicely designed {Ubuntu,GNOME,KDE} app?'
[15:18] <vish> godbyk: well we have the FDO :)
[15:18] <mgunes> godbyk, I've been thinking along the same lines for a while. the design / ux counterpart of http://producingoss.com would be awesome
[15:19] <godbyk> it's about, 'how do I ensure my app has a well-designed UX.'
[15:19] <vish> godbyk: if it is about every environment , it would end being very abstract
[15:19] <vish> it needs to be more specific
[15:19] <mgunes> godbyk, there are lots of existing books about that; this should perhaps be "how do I ensure my *free/open source* app has a well-designed UX, and how do I maintain it"
[15:19] <godbyk> vish: yes and no. I think there are two fronts that should be tackled:
[15:20] <godbyk> 1. the general design principles should be laid out in a manner that they're easily understood and applicable to the sort of work that FOSS developers do.
[15:20] <godbyk> 2. we can point at the specific UI guidelines for various distributions, desktop environments, etc. so they can get the nuts and bolts angle.
[15:21] <godbyk> I think the various HIGs cover the desktop environment-specific stuff.
[15:21] <godbyk> but they don't talk about any of the larger-picture issues.
[15:21] <vish> godbyk: http://www.freedesktop.org/wiki/  ?
[15:22] <godbyk> I haven't seen any of them mention, for instance, how you might read a bug report in the light of how it may be an overarching UX bug and not just a silly user who didn't read the docs.
[15:22] <godbyk> mgunes: True. But I suspect most developers aren't rushing out to fill their bookshelves with those books.  Otherwise we wouldn't be having this discussion. :)
[15:23] <godbyk> It's not so much about writing a book or building a website or figuring out which org (Ubuntu, GNOME, FDO, etc.) should be responsible.
[15:23] <vish> godbyk: i disagree here , we cannot get to be so abstract to cover every environment...  every desktop has a target audience [atleast its supposed to].. we cannont have a one-size-fits all
[15:23] <JanCBorchardt_> the ux-heuristics seem abstract and complete enough to be that, or aren’t they?
[15:23] <vish> cannot*
[15:23] <godbyk> I'm interested in instilling this design sense in the FOSS community at large.
[15:24] <vish> JanCBorchardt_: yeah , tagging is simple..
[15:24] <mgunes> right; if there was a book that we could point to as *the* primer for doing design-minded FOSS development, it would be easier to promote and get people interested in
[15:24] <JanCBorchardt_> vish, no, I mean not as bug tags, but as guidelines, as previously mentioned
[15:24] <godbyk> vish: You can for a number of the UX principles.  Fitts' law applies to all the desktop environments, for instance.
[15:24] <vish> godbyk: JanCBorchardt_: tagging works everything , it tags the problem , but how each desktop deals with is needs to be different
[15:25] <JanCBorchardt_> vish, that’s why I said the HIG patterns could be linked to ux-heuristics
[15:25] <vish> oh i need to revive and kill fitts!
[15:25] <mgunes> again, http://producingoss.com is a great example as a "go-to" book
[15:25] <vish> ;p
[15:25] <godbyk> vish: But yes, I envision that in addition to the truly general/universal guidelines, we will have to focus on specific environments to some degree.  (Though much of that should exist in the HIG for that environment.)
[15:25] <godbyk> vish: I know! I cringe whenever someone brings up Fitts.
[15:26] <thorwil> vish: there are a lot of things that apply almost independent of target audience. at least if you keep out certain disabilities, there are a lot of things you can say of human abilities, cognition and thinking. that is a base for a long list of rules that should be followed
[15:26] <godbyk> mgunes: that link doesn't work for me.
[15:26] <vish> godbyk: ok.. so you envision writing new laws kinda thing?
[15:27] <godbyk> I think that we should also discuss how developers can do some user testing, too.  (As if we didn't have enough to talk about!)
[15:27] <vish> kevin's law :)
[15:28] <godbyk> vish: I think we should explore the underlying principles and show how they apply.
[15:28] <mgunes> godbyk, works here; try visiting a bit later
[15:28] <vish> ok..
[15:28] <godbyk> mgunes: ah, it just popped up.  my internet is being weird today.
[15:28] <vish> godbyk: i think our first goal would be to identify the problems that are common to most DE
[15:29] <godbyk> vish: yeah. and I'd like to hear from developers about things they're interested in knowing about.
[15:29] <vish> godbyk: well , if they knew the problem, they wouldnt have the problem ;)
[15:29] <godbyk> it seems like a lot of complaints (in Ubuntu-land, at least) stem from a lack of knowledge of the design process and/or design principles.
[15:30] <godbyk> vish: if only that were the case!
[15:30] <vish> or maybe we should look at existing bug reports.. do you know about the needs-design tag?
[15:30] <godbyk> no, I haven't seen that tag.
[15:32] <godbyk> searching for tag:needs-design brings up all of 19 bugs.
[15:32] <thorwil> vish: damn, how to search by tag on LP?
[15:32] <thorwil> nm
[15:32] <vish> yeah , ubuntu bugs are https://bugs.launchpad.net/ubuntu/+bugs?field.tag=needs-design
[15:33] <godbyk> so either the tag is rarely used or those bugs get fixed quickly?
[15:33] <vish> several bugs are not tagged as needs-design though ;p
[15:33] <vish> godbyk: yeah , rarely used.. or fixed as seen fit by the developer
[15:34] <vish> godbyk: those are the _ubuntu_ bugs , there is probably something similar in gnome
[15:35] <vish> godbyk: well , several of the papercut bugs are needs-design ;)
[15:35] <vish> you could look there too.
[15:35] <godbyk> 'kay.
[15:36] <vish> godbyk: this should be a shorter list to look at https://bugs.launchpad.net/hundredpapercuts/+bugs?field.status%3Alist=CONFIRMED
[15:39] <godbyk> I guess another way to think about the book/website/whatever is that it should be a sort of be-your-own-design-team starter kit.
[15:39] <daker> godbyk, +1
[15:40] <JanCBorchardt_> godbyk, yes, we need to have people educated easy
[15:43] <vish> godbyk: if its for an app , where do you think a developer would look into? :)
[15:44] <godbyk> vish: can you rephrase the question?
[15:44] <vish> godbyk: lets say , some one wants to develop an app , where would the developer would look for guidelines?
[15:45] <vish> gah! sentence formation fail!
[15:45] <godbyk> gotcha
[15:45] <godbyk> I'd say that this kit would contain the general/background information on design plus pointers to HIGs for the various desktop environments.
[15:45] <vish> bingo!
[15:46] <vish> godbyk: can a developer develop an app for every environment at once?
[15:47] <godbyk> I think your notion of the design of an app is tied too closely to a particular desktop environment.
[15:47] <godbyk> Let's look at the GNOME HIG table of contents:
[15:47] <godbyk> http://library.gnome.org/devel/hig-book/2.30/
[15:47] <godbyk> There's a very small chapter that covers some basic principles.
[15:47] <godbyk> I think that needs to be expanded quite a bit.
[15:47] <vish> maybe we should expand it?
[15:47] <vish> :)
[15:48] <mgunes> godbyk, my worry is that a lot of the generally accepted UX / UCD wisdom on how to do good interaction design will not apply to the nature of FOSS development. and that is where this book / resource should come in: it should be custom tailored to the FOSS world. but that's no easy task; it takes surveying the existing methods that work, and devising new ones.
[15:48] <godbyk> I suspect the expansion would be enough to warrant its own document, though.
[15:48] <JanCBorchardt_> I was planning to write my thesis about something similar ;)
[15:48] <vish> godbyk: yes , but being an expansion of the 'gnome' HIG , would give it more value..
[15:49] <godbyk> mgunes: I think the underlying design principles apply regardless, but there are certainly FOSS-specific things we should address.
[15:49] <godbyk> vish: for gnome developers, yes.
[15:49] <godbyk> vish: but the info is also of use to kde and xfce devs.
[15:50] <JanCBorchardt_> so what would be FOSS-specific things?
[15:50] <vish> godbyk: i kinda think that when we design something it needs to feel native to the environment.. but i think a design for an app needs to start from the app's goal
[15:51] <mgunes> godbyk, principles do apply, but a lot of the time, the execution necessitates dealing with people, teams, stakeholders etc. of an entirely different nature. and the political economy of free software is fundamentally different to those of the corporate world or startups, for which classic interaction design guidelines are usually meant.
[15:51] <godbyk> vish: absolutely. does it say that in the gnome hig anywhere?  does it talk about how to ensure your app helps the user achieve their goal?
[15:52] <vish> godbyk: exactly! _that_ should be fixed .. :)
[15:52] <vish> godbyk: identify the problems in the existing HIG's and then fix them.. it is very easy to get very vague with this
[15:52] <JanCBorchardt_> godbyk, what would be FOSS-specific things?
[15:53] <godbyk> vish: don't you think that the knowledge of ensuring your app helps the user achieve her goal is applicable to more than gnome, though?
[15:54] <vish> godbyk: that works universally.. hence i mentioned it. but gnomeHIG might not have mentioned it.. [i dont know every part of it ;)]
[15:54] <mgunes> JanCBorchardt_, I think the advice regarding how to manage and maintain a project can and should be FOSS-specific
[15:54] <godbyk> vish: shouldn't those universals be present in some document that's independent of the gnome hig (or kde hig or whatever)?
[15:54] <vish> godbyk: what i'm trying to get at is.. if its suppose to be for ever environment , then FDO is the place to address them
[15:54] <godbyk> JanCBorchardt_: I agree with mgunes. I think the dev process is different enough that it's worth addressing.
[15:55] <mgunes> How do you attract designers to work on your proprietary, sealed-box project? You pay them! You usually can't in free software, unless you're a for-profit free software company, or well-sponsored foundation.
[15:55] <vish> godbyk: its no point in us, just putting something up in the wild , we need to work with upstreams..
[15:55] <godbyk> JanCBorchardt_: I suspect that FOSS developers take on a lot more of the design decisions than proprietary developers do.
[15:56] <godbyk> (only because it's usually a manager's (or someone else's) job to write the design spec. and the developers just implement the spec.)
[15:56] <mgunes> How do you define project requirements at the inception of the project? The answer for the proprietary / web world is "do user research" - how do you do it in free software? How do you avoid bowing down to random feature requests? How do you maintain a project's design focus in the light of new contributors coming in?
[15:56] <mgunes> etc, etc
[15:56] <JanCBorchardt_> godbyk, I was aiming for something specific but yes, it is really the whole thing that is different
[15:56] <godbyk> vish: well, I'm not proposing we just toss it into the ether.  It'll cross-reference the gnome hig, the kde guidelines, etc. and it'd be nice if the gnome and kde higs referenced this work, too.
[15:57] <godbyk> mgunes: exactly.
[15:57] <mgunes> these are matters where you can't take the canonical UX / UCD wisdom and apply it to free software
[15:57] <mgunes> new guidelines need to be developed, and existing ones solidified
[15:58] <JanCBorchardt_> mgunes, user research is possible in FOSS as well. But as always, someone has to JFDI :) – the real problem is communicating it to the developers (ideally by being one yourself)
[15:59] <godbyk> vish: I'm all for improving the GNOME HIG, but I think the core design principles transcend GNOME and that knowledge would be beneficial to developers in other environments, too.
[15:59] <mgunes> JanCBorchardt_, I wasn't arguing that it isn't possible, but that it needs to be done differently
[15:59] <JanCBorchardt_> or at least very involved with the project. We had that in the UX Advocates session at GUADEC
[15:59] <vish> godbyk: we should try at FDO then?
[16:00] <godbyk> vish: I don't know. I haven't been thinking about whose umbrella it fits under.  I'm still working on what info it should contain.
[16:00] <vish> cool!
[16:01] <JanCBorchardt_> godbyk, was that what you wanted to post to the ML? Or do you have a writeup somewhere in the wild?
[16:02] <godbyk> JanCBorchardt_: I don't have anything written up yet, but I'll post something to the mailing list sometime during the next couple days.
[16:02] <godbyk> I'll take our discussion here and try to summarize the points made (for and against the notion).
[16:03] <JanCBorchardt_> great! :)
[16:41]  * Emerling is away: Estoy ocupado
[16:44] <nigelb> !away | Emerling
[16:45] <Emerling> ok, iḿ sorry
[16:45]  * Emerling is away: Estoy ocupado
[16:45]  * Emerling is back (gone 00:00:08)
[16:46] <Emerling> i be in very rooms chanels and no look it channel ,, (my english is bad)
[17:45] <j_> hola, como puedo acceder a una asesoria para instalar ubuntu en un pc
[21:49] <Ganesh_R> Hi is this the support channel?
[21:50] <czajkowski> Ganesh_R: try #ubuntu this is a meeting channel
[21:50] <czajkowski> Ganesh_R: or there could be loco support, have a look at loco.ubuntu.com/teams
[21:50] <Ganesh_R> Thanks
[21:51] <czajkowski> np