KDE Usability Report

From kde-usability Fri Aug 17 11:15:30 2001 From: Robert Watkins Date: Fri, 17 Aug 2001 11:15:30 +0000 To: kde-usability Subject: KPlato Usability Report X-MARC-Message: https://marc.info/?l=kde-usability&m=99804708027013 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--0-21233885-998046930=:86449" --0-21233885-998046930=:86449 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Here's my report on KPlato. Since this project is in the very early stages, there isn't a user-base to gather comments from. So what I've done is gather comments of pitfalls people want to avoid as well as wishlist-types of comments. Any and all comments are welcome. Thanks, Robert ===== __________________________________________________ Do You Yahoo!? Make international calls for as low as $.04/minute with Yahoo! Messenger http://phonecard.yahoo.com/ --0-21233885-998046930=:86449 Content-Type: text/html; name="kplato-2001-08-16.html" Content-Description: kplato-2001-08-16.html Content-Disposition: inline; filename="kplato-2001-08-16.html" KDE Usability Report

KPlato Usability Report

1 January 2001

Resources: KDE Usability Study - KDE Homepage

Written by: Robert Watkins

C O N T E N T S

ID	Item
#1-1	End User Scenarios
#1-2	User Goals
#1-3	User Interface Requests
#1-4	Lessons learned from MrProject (Gnome-based project management project)
#1-5	Request for Use Cases

I T E M S

#1-1	End User Scenarios
Description	Take the mythical XYZZY corporation - they make toys and sports products. It has a few different people: Abigail, who is the Managing Director; Bob, one of the five design team leaders (the others: Bill, Brian, Bette and Bruce (his real name is Eric, but he's Australian:) Charlie, the financial controller Deb, who is in charge of marketing Edward, who is running internal production Fran, who runs the logistics team (warehousing, distribution and materials sourcing) So Bob, who has just been assigned responsibility for development of a new scooter with a V8 motor, is probably a mechanical engineer turned manager, and is busy trying to assign his design engineers, drafters and test equipment to get the widget out in the time frame. He gets out kplato 1.0, opens the document that has all his existing work, looks at the existing tasks, figures out who can be re-assigned (full or part time), and builds an outline of the work tasks that he needs to accomplish to get the scooter design done as a new WBS element. Bob then calls a meeting, explains the new tasks to the relevant people, and assigns tasks using the kplato to KDE-PIM interface. When an individual, lowest level WBS element is completed by whoever it is assigned to, the KDE-PIM interface updates the kplato document, automatically. Deb knows that a V8 scooter is going to take some serious selling in the safety conscious marketplace, and decides that she needs to sort out how it is going to fit in to all the other marketing she has to do. She also uses kplato 1.0, and links across to Bob's document to see when things are going to be finished with the design, since that is the earliest a prototype will be available. [ This means that one part of Bob's project ("running the team") becomes a constraint on Deb's project. I'd consider that this means that Bob's project is a sub-project to Deb's project] One of the outputs of the scooter design that will come from Bob's team will be a Bill of Materials, that lists all the things that it takes to make one scooter. This goes to Fran, who has to get the materials, and to Edward, who has to assemble the scooters. Edward will also get some other drawings, and some assembly instructions. Edward, who is something of a geekboy, is running the new kplato 1.3 release. Edward has the ability to insert the various assembly steps and the Bill of Materials into his kplato document, and has some extra interfacing code that looks at the current inventory status (maintained as a legacy PostgresSQL database by Fran's team, althought Edward hopes for inventory management in the upcoming kplato 1.4 release), the machine capacity and the required production numbers (from Deb's KSpread document), and can then schedule all those resources using kplato's constraint fitting algorithms and a lot of CPU cycles. [This means that you need to be able to insert "modular" work packages into higher level documents. Those work packages are sub-tasks, held as seperate definitions, but instantiated as part of Edward's kplato document.] Deb can now take the production schedule from Edward's kplato document (even if Deb's 1.0 release can't see all the fancy work behind Edward's 1.3 release, Deb can still get the fundamental schedule out) and schedule the "rollout" of the sales promotions and give-aways as part of her document. [This means that Deb's database now has multiple constraints, one based on Bob's prototype delivery, and several based on Edward's production runs.] Charlie can access the kplato documents of Bob, Fran and Edward to determine spend spread (when the dollars go out the door) for prototyping materials and equipment, raw materials, and consumables respectively. He can then access the kplato document of Deb, to see when the revenue is supposed to come in from sales. If this shows a problem, then they can all get together, replan, and resolve the problem. [ This means that Bob's, Fran's, Edward's and Deb's projects are probably sub-projects of Charlie's KSpread document, since extracting constraints isn't any different to extracting costs] Abigail, who isn't too good on kplato scheduling, but does like the quality of the Gantt chart layout, sends email to some of the people, and gets some dates, extracted by hand, from each of the other kplato documents. These are then cut'n'pasted into kplato, and the output chart is then linked into KPresenter, for a presentation to the Board. After she does the kplato course, she will know that it is possible to extract the dates automatically and have them linked. But she won't, since email is less work than sorting through the detail, and Managing Director's are like that :) 1. Plan out the entire network at a high level of detail. 2. Do the detailed breakdown and assignment of resources for the next six months (as this about as far ahead as I can accurately guess resources) 3. For the rest of the high level, I would assign estimated duration based on experience (i.e. other projects of similar size), and assign a risk that indicates my confidence in that estimate. In order to be able to do that we need to be able to associate a risk/duration with a task alone. One way around this would be to assign a default resource to a task if there isn't one. We could then enforce the constraint that only task/resource pairings have durations and risks (come to think of it this is a good idea, and could solve some other problems I see arising). I need to do some thinking about this, because there are a few problems to solve: 1) The constraint that assigned risk (calculated is another matter) only exists in a task/resource pairing. 2) An effort is associated with a class of resources; i.e. adding a computer doesn't affect the number of man hours available. 3) Technically a task alone does not have an effort (effort is assigned time, duration is calculated time). Example "Develop x module" requires 150 manhours -- this only makes sense if a developer is assigned.
References	http://mail.kde.org/pipermail/kplato/2001-June/000049.html http://mail.kde.org/pipermail/kplato/2001-July/000150.html
Proposed Soloution	The first scenario points out some likely un-used functions of KPlato, however, it does point out some specifics to implement. The second seems more plausible, but is less detailed. Additional Use Cases are needed to be able to complete the Features and Deliverables list. I'd suggest doing a paper prototype exercise that has the project managers that are posting to the list give feedback on how they would use the proposed system based on a very rough set of 'screens'. Then take these results and incorporate them into the features list, list of additional questions and a new set of paper prototypes to iterate the process.
[contents]

#1-2	User Goals
Description	It would be real cool if this product were to support Timeboxing. I think this is a real necessity in this day and age of DSDM, RUP, and other RAD based methodologies. Will there be the ability to resource share across projects so that we don't over-schedule? Also I prefer to be able to allocate a % of the resources work day to 'admin' so that I know how much is truely productive for my project(s). One feature that I have seen nowhere is the ability to define a task or resource as interruptable or non-interruptable. Certainly software folk are familiar with these concepts, but automatic scheduling software that I am aware of is not. Interruptable tasks and resources could (should) also have start-up and/or shut-down penalties associated with them!!! *Allow the ability to generate a delivery date and buffer (e.g. 30 +- 5 days to complete) based on assumptions about the estimates to complete tasks and the confidence in those estimations.
References	http://mail.kde.org/pipermail/kplato/2001-August/000184.html http://mail.kde.org/pipermail/kplato/2001-August/000182.html http://mail.kde.org/pipermail/kplato/2001-July/000153.html http://mail.kde.org/pipermail/kplato/2001-June/000089.html
Proposed Soloution	I'm not sure what Timeboxing is, additional information would be needed to look into this further. Managing and reporting on resources seems to be an important area. Add these to the Features and Deliverables list and do some user testing to determine what's really needed and what else is missing.
[contents]

#1-3	User Interface Requests
Description	Alert to the user if end dates cannot happen for a task or project due to prior tasks falling behind or scope change. Alert to the userover-scheduled resources for a particular timeframe. Specify tie-breaking rules for resources/tasks if there are competing priorities. Alert when tasks are past-due To be really useful, task durations and effort should be displayable and enterable in minutes, hours, days and weeks. I would prefer to have resources listed like CA-Superproject, not in a column like M$ Project. *Don't change values that have been manually entered
References	http://mail.kde.org/pipermail/kplato/2001-August/000186.html http://mail.kde.org/pipermail/kplato/2001-August/000181.html http://mail.kde.org/pipermail/kplato/2001-June/000059.html http://mail.kde.org/pipermail/kplato/2001-June/000089.html
Proposed Soloution	These are good candidates for user testing with paper prototypes detailed above.
[contents]

#1-4	Lessons learned from MrProject (Gnome-based project management project)
Description	* Dependencies... The "link" button isn't very user friendly. As I'm building a project, the tasks aren't necessarily listed in any meaningful order. Setting dependencies helps me determine what order they should be in. When I set dependencies through the interface, the direction of the dependence is determined by the order on the task list. I'd prefer to to have another tab on the "Task Properties" dialog call "dependencies" where I could manually enter the ids of other dependent task" (This links would have to be preserved when I reorder also). * Get that % complete feature working! * Identify resource conflicts. Let me know if I've assigned "Bob" to two tasks at the same time. * Let us be able to manually enter the duration right on the gantt chart screen. We can grab the bar in the can drag it, but we can't type in "20 hrs". * Let us drag-n-drop to reorder items in the task list. * The ability to set priorities and have a sort feature which would order the list based on this value. The nesting would have be taken into consideration. For instance, if a task is nested 3 (for example) level deep but has a very high priority, then it's top-level category should move to the top of the list when sorted. - * The ability to "check off" completed items. Checked off items should be flagged as such (maybe the gantt chart should turn red). It would also be nice to hide completed items. This would make viewing large projects much nicer.
References	http://mail.kde.org/pipermail/kplato/2001-August/000180.html http://lists.codefactory.se/pipermail/mrproject/2001-July/000248.html http://mail.kde.org/pipermail/kplato/2001-July/000171.html http://lists.codefactory.se/pipermail/mrproject/2001-July/000245.html http://mrproject.codefactory.se
Proposed Soloution	Generally, keep an eye on the discussion forum for MrProject and make a note of their lessons learned and incorporate into future development plans.
[contents]

#1-5	Request for Use cases
Description	Request for Use Cases
References	http://mail.kde.org/pipermail/kplato/2001-June/000106.html
Proposed Soloution	Develop Use Cases ;) Seriously, formalized use cases can be developed only with a clear understanding of how the users will be using the system. User Scenarios and User Testing will be the key to this understanding.
[contents]

KDE Usability Study Maintainer: Jono Bacon

--0-21233885-998046930=:86449-- _______________________________________________ kde-usability mailing list kde-usability@mail.kde.org http://mail.kde.org/mailman/listinfo/kde-usability