Design Presentation

• Led by Sheila Mooney
• Notes taken by Priscilla Chung

Session Notes

• Going back some context of the designing process had started
• Mimi forwarded some pages back in 2004
• Roles and PM does on the wiki from Chao
• Mimi and Chao working with Mitch coming up with the priorities
• People having insight, not in the early design
• Met 3 times a week.
• Ted's first week in the office attended one of these meetings
• Sorta like therapy
• 20 or so messages, never posted to the list when she first started
• We can evolve and adapt with the needs of the
• trying out a lot of new things. Not a lot of people
• Evolving and learning from as the process progresses
• Research
• visual design, paper prototypes, mock-up
• socializing things from the team.
• a lot of things about the design we don't know
• very iterative process
• Mimi wrote up a long time ago really hasn't changed
• user centered design, target
• relating everything back to the target user
• building community, 20% projects
• justify every feature, improve the chances of
• create a coherent set of work flows
• a way we can make decisions and m
• open source design, projects we can follow and compare to? No formula
• we're trying a lot of things, and it may not be successful
• frame issues to be discussed.
• for design, to come to the design table, people need to learn and acquire
• a lot of people can't follow the list, requires so much effort.
• the reality, in order to participate in some level, you have have to spend the time, commitment, people to learn the skill-set they don't already have
• we're trying to make that easier for people to give people a hook on the list.
• We'll see if this feature is useful?
• frame issues on the list
• how do people feel about this
• come with mock ups and visuals on the list
• open design issues on Tuesday
• deciding what this should be and driving them, and there time when a developer can be leading and drive the session on Tuesday.
• To get involved.
• It's a very hard problem
• We'll like to hear people
• what they think work well, what does not work well
• what are people's experience organizations
• There seems to be a lot of tension with development and design

Comments from the team:

• Jared: What's our process with balancing what people are going to work on.
• Katie: Socializing ideas. First take of the design. There is history and formalized, some coherent idea that's been thought through. Getting everyone to get feedback on that idea on the list. Communicate the spirit of the design and a stake in the ground. Ideas that match the design. Hard and easy to implement. Some consideration is made about the proposal, what's hard to make. There's sometimes misconception on what hard and easy. Sometimes it needs a second proposal. Breaking that down to what work is there? Breaking it down into tasks. Often developers learn something when implementing that design. Sometimes that brings up more issues. PM role to make the decisions that are feasible and fit in the schedule.
• Jared: many open source projects, here's an idea and it gets tweaked
• Mimi: We try start out with the spirit of this design. Open up discussion on lots of different ways of doing something. Sometimes it's abstract and to wrap yourself. Waterfall design is a problem, because the workflow can break down.
• Sheila: Independent detail view feature.
• Mimi: To solve someone's problems, we can't just hand over a design and have the developer decide on what they want to implement.
• Sheila: A lot people come with cool features, and we have to abandon. It's not about we're not going to do this for a reason. It's about what we have to sacrifice in order to do that work.
• Mikeal: I trust the design process to come up with features. Only part that break down, feature list and becomes a development tasks. Contributors on the list, there most likely not going to be on the design list. It would be nice if we have all the things we're going to do.
• Ted: Road map
• Mimi: What is the opportunistic things we have to do? I'm fixated on the core set of features of things that need to be done.
• Matthew: How does this big feature work, how it behaves?
• Mikeal: SimDesk^? guys, when do we put in the things in, and have a process for that. having a form for people to justified that.
• Sheila: Never a great way to get people together to mid level plan. Useful to expose that people. How is a good way to present this to people. This is what PPD are trying to accomplish.
• Mikeal: every feature people going to…
• Bobby: how are things which are not on the PPD radar.
• Katie: This is the GAP we are noting. And someone will walk out of this sprint to have this tasked. If someone does something about the design.
• Ted: If someone comes along and it doesn't
• Katie: is there a doubt?
• Mikeal: Jared stuff does need to be…
• Jared: PPD need to get the issues from Jared. User weight from design are heavy weighted.
• Matthew: Very web UI, based on the desktop. i.e. the font issue which was originally focused on the desktop
• Sheila: Well you sent it on the list and that is the right thing to do.
• Jared: Perceived gaps. Can't be passive aggressive.
• Ted: Can't say you want to be involved in the process, but not involved at all. Management is going to fix the road map. Everyone that has a stake
• Katie: PPD Program, product and design.
• Mimi: Program role that is end user desktop is from the design side. Some are development requirement, if I'm feeding in the design, developer is feeding in technology.
• Mikeal: one singular line, more like a hand off.
• Sheila: end users stuff, we're missing lots of other stuff. Desktop that is not end user stuff.
• Ted: stuff to support the dev platform, 3rd party requirements.
• Mimi: design requirements are public, engineering are not so public
• Matthew: more of the code and less of the documentation. May not be the right thing, but is currently what is going on.
• BCM: Why people use the technology only though GUIs. It's up to us to explain. Originator of engineering requirements for 3rd party requirements and for me to list them and explain them. PPD should learn in an educated way with everybody else. I feel like none of us have tried to do
• Sheila: even w/out a a GUI there is a target user
• Ted: even if there is not GUI there
• Jared: PM be pulling that information. And better identification who that person is.
• Katie: People taking on the role.
• Jared: Jared the PM for the hosted service
• BCM/Katie: Cosmo 0.5 PM, there is GAP
• Jared: I need features and it's the role of the PM to pull that features together. I've been off to the side.
• Mimi: Process of design target user, that is a learned skilled for a designer as well.
• Mikeal: if the developer know the feature and wants it in, we don't have time to
• Mimi: It's the artifact of the spec. Not specific design, it's specific to open source and get people on board. You have no power unless you have people on board. Just a part of what I have to do as this process.
• Mikeal: process with 3rd party user, to what level people justifying this feature
• Katie: Worried about too much bureaucracy
• Ted: Make a list for the server side as well. Make a list of features (Mikeal)and I will nag people to get it done.
• Jared: Cosmo team not having any commits, people blocked on the merge. Plan issue. Road map. Get features together to prototype. We have a sandbox to It would be nice to have more commits to trunk and moved to a branched to be released. Signed off and polished
• Katie: there is a test menu on the desktop. And that evolved, morph and changes. It wasn't even on the roadmap and inspires us to do that.
• BCM: we have enough to handle for individual releases. A little bit of a planning window. Dead time to fix bugs, I don't find a lot of time unless something inspires me at night. Or repository I did over Christmas last year.
• Katie: Jared seemed like people were blocked.
• BCM: Hibernate and merge, email threads and working with the team. A lot of other work, I was blocked on coding.
• Matthew: I could get more done with design direction. OSCON presentation.
• Bobby: I am concerned about vision shorter release cycles. The more context, plan longer and more ambitious stuff.
• BCM: We don't have great process.
• Sheila: there's the UI, I agree back to the GAP…
• Bobby: There were times during the planning process.
• Sheila: was the planning process too long?
• Bobby: I don't want there to be down time.
• Jared: a richer road map would have helped you with that aspect.
• Bobby: Scooby/Cosmo is still new. Things are trickling down.
• Sheila: a lot of stuff going on last week.
• BCM: road map to allow developers to noodle on, planning time developer can also prototype on things. Overlap planning
• Katie: PPD needs their attention, but then that takes time. Engineering is a little bit stuck in the cycles.
• Katie: project is further along, road map…
• Sheila: deferred bugs people can work on. We wanted to do some design sessions. We needed to have intense design session.
• BCM: We just need to suck it up and have attention.
• Katie: Philippe will know I know this will be implemented. If PPD is interrupting the dev time
• BCM: If know on Thursday there are meetings, I'll dedicate for Tuesday afternoon for design.
• JohnT^?: Some reality, that was on the 0.3 plan that was not worked on. Time-zone, These were items that need to worked on the future.
• JohnT^?: Used a lot of time looking Dojo and prototyping, magic URL and shared discussion. Interacting each other and that is good. But not about the total lines you write, but also what you are learning from each other.
• Matthew: I spent time looking at the layout. Too many browser specific hacks,not encourage outside people to do that. It was outside the tree.
• JohnT^?: There were things in the plan, but were deferred, but we need to do a better job, of communicated better.
• BCM: Something seems a bit backwards. Not to spend time on the low priorities. If that is bandwidth
• Matthew: Recurring events. That is not a low priority.
• Katie: We set these goals for the release, dog-fooding. It has to be rigid ordering.
• BCM: Why do the lower priority work then to do?
• Katie: Developer knows what they need to do and should work on it. No more input with PPD.
• Mimi: Want people to learn and understand, other things that doable on Chandler
• Katie: Pipeline to happen. First issues that come up…
• JohnT^?: Here is a bunch of things that worked in the past. If there is really time and pull the feature forward.
• BCM: time based release and don't like that at all. We're trained experienced. Do it until it's done. The other way is a lot fuzzier and dependent.
• Matthew: There were dependencies earlier on before the projects were merged.
• Mikeal: Things are still dependent.
• Jared: Hosted service.
• Katie: Pick one specific feature and focus making that piece work. I too have felt time based release to be difficult.
• Sheila: The stake in the ground.
• Mikeal: I never think the date for the deliverable to QA is never going to be the date…
• Ted: We have had variations.
• BCM: Eliminate the confusion and we won't use the time based. Target date. I don't have problems forecasting dates. I won't say this is a drop set date. When I look at specs, one section declaring one goal that are inconsistent to another goal.
• Mikeal: It's sort of impossible…
• JohnT^?: you can't reliably done predict how long it's going to go.
• Jared: We're not blocked on coding but the number. I'm a fan of time based release if it works like clock work. It's a completely different model. You just push the release forward, but don't ship current
• Katie: it's wildly unsatifying (in reference to a time based release).
• JohnT^?: Scooby 0.2 it was a time based, not just putting something out.
• Jared: time based release-I think of every two weeks.
• Katie: we do something like that which is called a check point.
• Jared: release issues, the more we do that the better we do that
• Katie: there is milestone for people to shoot for.
• BCM: We keep talking about the GAP, and this would solve everything. No context. A lot of stuff in the spec requires context that refer back to previous conversations. On the spec, there was more elaboration. It was in a long list. I want to help out, I didn't know what the feature is supposed to be. If someone want to write the code. I have
• Jared: Takes a huge amount of time to carry all context all over the wiki pages and specs, and design list discussion. Faster then adding on top of.
• BCM: adequately to communicating on what to do. Make it explicit. Recurrence so detailed, the thought to spec-ing it out. The goal is to put the PTO on the office calendar. Is there a subset of putting recurring events. The
• Mikeal: implementation details are
• Bobby: Maybe the developer should try to go ahead and take a stab ad adding the level of detail of what they would like to see.
• BCM: the role of the designer
• Mimi: We're not doing a waterfall design. Everything
• Sheila: The stamping spec, I had to have people to say something about recurring event. Unstamp, and those discussion. When no one comments, then it's
• Matthew: put something on the list. Have we
• Jared: Have we had a spec review.
• Sheila: Desktop spec and point to previous documents. Comments from other Valuable for other people to read
• BCM: We have to force ourselves to do it.
• Mimi: Keep track of this use case. It's basically the target use case. This problem writing a spec. Keep in mind this use case: Priscilla writing a spec. And people not finding context.
• Sheila: It would be helpful beyond. This is the target user, this is what we're focused on. What other feature
• BCM: Clarification, I know that is going to happen with this one. I know it will get better.
• Sheila: the specs is not done until all stuff is done. Scenarios.
• Mimi: We were going to ask people what the design development process they've been in.
• Katie: Jared brought it up
• BCM: Usually is the product owner and sticking their nose in everything, describe everything. They fail that they are unable to communicate everything. The primary input in the technical requirements. Technical people to evaluate everything.
• Mimi: How does UI
• BCM: Mkt requirement, non functional requirements stability etc. to come in before. Describing the actors/use case are not always accurate. It takes practice the use cases exists. We don't know what list is, the pieces talk. Add to our process moving. Us to writing down what that is, and educating that on what it is. Collaboratively. I have been working w/out specs. Hopefully everyone to know what ATOM support is what it means and what we need this? Assign priorities. Assign priorities on what Jared needs. All the process stuff, is typical. Those are small challenges are and what people want to do.
• JohnT^?: In the past I've worked with people in the design, everything I saw were wire frames/features would flow. High level design, dive down with use cases and put together. Read more about schematics on the list. The developers to have an idea of the high level design. If I have in my head on what the user's perspective on stamping and
• Mikeal: To go over the intricate details
• Mimi: use case to me, is someone entering their pto. It's not person double click on the calendar to complete work flow. If you start with the use case, the wire frame/storyboards fall out of the work flow. The use case I come up with or. Our job is talk to people to understanding all the problems in their life. What are the different wire frames that can serve that need?
• Mikeal: when developers are involved in the design process, when it's handed over as a features.
• Mimi: The spec is we're starting to engage in the process. Is it A. understandable. B. doable. or is there a better way of building this feature.
• Sheila: it's intentionally fuzzy. We've heard feedback that developers want feedback on the spec.
• BCM: Maybe we should confuse the two phases. Who are involved in that activity. When I look at a spec, this is what we all agreed to build. What I don't want is super vague list of ideas and things identified. I want a tightly scoped plan. If it's my responsibility, is the actual flow framework (?)
• Mimi: early on I spec-d out this spiral diagram. user research, info architecure/structure. Item that can change and add attributes to itself. Worflows that flow out of the use cases. Information/visual design. Things that come at the end solidifies it. In the design process. Mock up of stuff to test ideas out.
• JohnT^?: What I want to get to, when I read the detailed, I want to have a level goal of what this feature. There are only a few things people
• Katie: Presentation on what Sheila is doing is to help that. To digest it easier.
• Mimi: It summarized all the things BCM is wanting. Yeah the mid-level presentation Sheila has been doing.
• Ted: It's not always clear, this it he first cut, we're looking for other alternatives, second part which we need to define the separation on this is the spec we're planning on doing.
• Katie: pull back from the details and it's hard to follow the details
• BCM: the proposal stage, when we get to the detail spec stage, we're getting closer to the technical. Everybody should be bought in to it by then and have participated.
• Ted: Design and engineering team to have some responsibility to
• Katie: Recurrence is a good example of the engineering team to help writing in the spec.
• Jared: Diagram to be good about communicating, not like wire frame diagram. Spreadsheet and grids. Stickie plan. We've heard about spec being too long. Standardized formats for proposals. there's a list of things of knowing why things are important. Standardized template on overall goals.
• Mikeal: There is a group of people who want less people and some people who want more detail. a
• Sheila: All projects are different. I'm going to write this spec and having a formula is not really. Finding out the right format of spec.
• JohnT^?: the spec you put out for the design. And a spec for implementing the idea.
• Sheila: some developer do not want to know the proposal, and want to see the spec.
• Mikeal: We really want something in writing, and discussing that. If we come up with name for those
• Mimi: We have tags and have names for the proposals
• Katie: Yes there is an assumptions, you and bear having the most difficult to follow the design list.
• Bear: the new summary to be do exactly that and I find the area. I tried to read everything and run out of time.
• BCM: Structurally sound. Doing things on the design list, I just want things to link back to the design discussion. Not just a link at the top and bottom. People to cross link. I use the summaries too!
• Sheila: there is some summary that
• JohnT^?: Other org. UI/Design team. Releases and date. UI to get the best user experience. PM get the project out on this date. Proj. Mng. Customer needs it to sell it. My first the three role can exist in one person. This can be more of a concern then PM role can become more inter
• Mimi: Much less experience, there are mkt req. and engineer. It didn't makes sense, UI were trying to building the best experience.
• JohnT^?: Build quick and this is not, not considered high priority
• Mimi: what people are willing to pay for, opposed to we're not trying to optimize for dollars. Be dollar useful enough to sustain ourselves.
• Mikeal: quote from Bobby, "We're not making software to make money, we're making money to make software"
• Katie: we might face some hard things, we're this faith we're going to find a path. Being open to features to respond
• Mikeal: I think we might be able to get donations as people are as interested in Agenda
• Ted: We've not really started, we want use to go through the exercise.
• Katie: There is this other context. The big challenge is to build the real thing people want to use.
• Mikeal: People were upset on not working on the four weeks and we should have been a room and make the decision. It took two weeks.
• Katie: I feel like if we're in a room, would it have been a useful?
• BCM: I didn't bring it to a close because I was working on other things. All the thoughts were organized.
• Mikeal: I would still be on a thread. If I would still be on the list, the way we were exchanging the idea. I'm not saying we should have hold a meeting and make the decision.
• Mimi: Who takes responsibility is it to summarize? I think some obvious ones that is the PM or dev manager, there is a clear owner. There isn't a clear owner for the issue.
• BCM: I didn't want people to reopen the debate.
• Sheila: It's important to summarize the work
• Ted: people are going to be better at summarizing threads
• Katie: summarize or last call. Boost conversation to go better.
• Katie: what am I getting out of this meeting? I want to make sure we're getting a decision. Maybe that can be done with a last call.
• Mikeal: I have questions why this person thinks this way.
• Ted: summarize those. Even put up a skeleton of something, is putting up the general outline. The sprint get people where they are emotionally. Apache has face times two days before the conference. Sit down and hack out whatever.