Forum OpenACS Development: [dotWRK] what it should become

1: [dotWRK] what it should become - part deux

Posted by Jeroen van Dongen on 03/22/03 05:03 PM

From the thread where we discussed the initial firestarter with respect to 'what dotWRK should be', I gathered the following.

First - what I called 'dotUmbrella' in my initial vision statement should not be part of dotWRK. It will mostly happen, but as part of folding parts of dotLRN back into oacs. In principle Don takes care of that.

Second - the verticals I mentioned were not really responded to (except for one case) and I guess I better drop that part for now.

Leaves us with 'applications'. From the various messages I've gathered the following list of things people seem to be interested in:

project management
- project repository
- wbs and scheduling
- cost-estimation
- resource mgmt
collaborative task/todo
- linked with projects
- stand-alone
facility booking
holiday booking
timekeeping
expense booking
statistical package (?)
calendaring
reporting/charting
wiki

Obviously, as noted on several occassions, some existing packages are dotWRK candidates as well - these are just the 'new kids on the block'.

I'd like to thank all for the input so far. Having said that I have to say that Peter Marklund made some interesting non-technical points (link to message). For this stage, the remark I think was most usefull is

"""It is not entirely clear to me what kind of functionality all applications in the list above are supposed to have. Coming up with a fictious but representative company that would deploy dotWRK, along with a couple of employees using the systems, and how the system helps those employees accomplish their day-to-day tasks would be immensely useful (see Lars's user-centered design documents for inspiration)."""

I've read Lars's documents, and I like the approach. If you all do as well, I propose that we indeed build a fictious company (on digital paper of course). Is the following something we all can live with as the next steps?

construct a fictious company and personas
create a number of use-case scenarios
use that to come up with a functional design and a datamodel
implement.

If you do - please don't hesitate to send in some ideas with respect to the first issue. If you don't, please tell us why and what approach you would like better (it's a community process after all

On a side note, I was giving the above list of applications some thought:

I kind of missed the point about the 'statistical package'. Can someone elaborate on that?
man-time and facilities are both 'resources': they are in limited supply, sometimes available and sometimes not, etc.
- Holiday is actually a cause of unavailability for man-time. Just like 'maintenance' is a cause of unavailability for tennis-courts.
- They also have a certain unit cost per time period.
- To cut it short: perhaps we should implement the generic concept of a 'resource', of which 'man-time', 'tennis-courts' and 'meeting' rooms are special descendants.
- Perhaps holidays can be seen as 'events', just like maintenance? Can the ACS-events package do some good here?
- Reasoning this way it actually makes sense that calendar items are 'events' (a task is also an 'event' - and makes a particular (human) resource unavailable for other things!).

2: Re: [dotWRK] what it should become - part deux (response to 1)

Posted by Roger Metcalf on 03/23/03 03:51 AM

I'm a little late in contributing here but would like to describe my focus. Most of what I have to add is at least implicitly present in what's gone before but I'd like to make a couple of things more explicit. The background on this is that I'm currently involved in a process improvement project at work as well as an intranet prototype (OpenACS in fact) to support a complex software product and organization, and I'm wishing dotWRK were finished!

The central object of processes we're trying to improve is information. Specifically, the information is realized in the large number of artifacts that are produced and used by various work groups during the various life cycle phases of a project. I think these basically constitute what's referred to elsewhere in this forum as the "project repository" or the "document storage". But these are central, not incidental.

The artifacts we'd like to have in the project repository include RFPs, contracts, emails, minutes, requirements, designs, code modules, sources, executables, environment setups, scripts, test scripts, test results, deficiency requests, etc. There are also less tangible items such as processes, roles, tasks, schedules. These can be in the form of documents, spreadsheet, code modules, etc. They may be internal artifacts or external deliverables. They may have multiple revisions, baselined versions, released versions. They may be part of a composite artifact or identify group of artifacts -- they have structure and relationships and owners. There are processes, owners, and different repositories. These artifacts correspond to Software Configuration Items (SWEBOK term) but we're just calling them CIs (configuration items) since some aren't software.

The first point about these CIs is that they are the tangible results of work.

Work products are the whole point of workplace collaboration and seem to be the key central objects of the entire organization.

To be explicit, nearly everything else on the intranet is related to these artifacts in some way -- creating, reviewing, approving, publishing, scheduling, time tracking, task management, departmental structure, etc. If we were finished then requirements could be traced to original sources, fixes to code modules, enhancements to functional modules, estimates to code metrics, etc, etc. The artifacts are the information. And there's a lot of them. This is almost starting to sound like an MIS!

The last point is that the intranet's reason for existence (in our view) is to provide support for workplace collaboration.

The workgroup is the producer and a consumer of work products.

I think the concept of Workgroup might also be key and useful for dotWRK. The interesting thing about workgroups is that they may, or may not, reflect organization structure. A workgroup might be composed of strictly departmental members, or organized by product, or by client, or it might be a cross-organizational team that doesn't fall under any department or product or client. The cross-organization type of workgroup is the one that can benefit the most of all from the intranet if communication across organizational boundaries is sparse, as is frequently the case. So departments, products, projects, and workgroups may be interrelated in various ways. And of course the input for some workgroups is the output from other workgroups, etc.

I know much of this is specific to software development but it isn't all. There are contracts, requirements, designs, deliverables, documentation in non-software settings.

In summary, I'm suggesting that rather than accumulating a set of things that seem workplace-related, like project scheduling, timekeeping, expenses, holidays, document storage, etc. (all probably needed), instead choose a core concept for the center and build around that. I suggest the core concept might be work product (or a better term) which is an information asset that is the result of the work of a work group in the workplace (and supported across the entire lifecycle by dotWRK... if only!)

3: Re: [dotWRK] what it should become - part deux (response to 1)

Posted by Ben Koot on 03/23/03 09:53 AM

I thought it could be usefull to take notice of this link related to workflow.

As far as setting up a demo company, I might have a usefull addition. As of next week I will start publishing a secretary handbook, 50 pages of minute business procesess of one of the Dutch secretary's in my network. It will include every aspect of day to day opeations of the Automotive department of a major european car company. The idea is to to find out how the info in this work document can be translated into OACS functinality. I have a group of 10 secreetaries onstnaly testing the ideas I come up with, (daily on-line) so that could be usefull for the project.

4: Re: [dotWRK] what it should become - part deux (response to 2)

Posted by Jeroen van Dongen on 03/23/03 12:33 PM

Separate from the dotWRK stuff, I've been playing around with the content-repository, cms and file-manager packages to see if I could come up with some generic object-storage/browser thingy. Originally my idea was to make sort of a 'stand-alone' version of the cms sitemap - a windows explorer like interface to the cr.

The basic idea is that one defines content-types and those content-types are 'all-in-one'-packages. They define a datamodel (leveraging the cr) as well as an API and templates for using them. It's then possible to use a generic explorer-like interface to interact with them. Each time a user wants to do something with the item, the generic interface figures out what template to use (standard cr functionality) and forwards the user to that template.

However, Roger's remarks actually triggered another (variant of that?) idea. How about creating an MS Outlook like application? Basically outlook is nothing more than a tree of folders containing objects. Each folder contains a particular type of object. E.g.
- inbox: folder with only mail objects
- tasks: folder with task items (shared by a group --> collabotive todo list)
- contacts: folder with contact objects
- notes: ...
- ...
Most objects allow the user to attach other objects to it (e.g. tasks object allows files to be attached).

Folder views can be customized and there are aggregate views, like 'outlook today' that combine information from multiple folders.

It's just a rough idea - I've not yet a precise idea how I'd see this in the context of dotWRK. Perhaps as a concept for the personal portal?

Some thoughts:
-- Every user or workgroup has their own set of folders, with the content-types they need. By using queries or symlinks we can e.g. make shared todo's, defined in the todo list of the group, popup in the users personal todo list as well.

-- A projects wbs could be expressed as a folder containing 'project task items', phases expressed as subfolders. This WBS/schedule folder then can have several views (e.g. a GANTT-view or a PERT-view).

Would this pig fly?

5: [dotWRK] work products at the core (response to 2)

Posted by Zach Thomas on 03/23/03 10:04 PM

You are right on the money, Roger. Everything in the workplace stems from work products (and that's a fit name for them as well).

At my company, the email system is expected to shoulder the burden of shuttling every work product back and forth. Revision control is nonexistant and everyone's inbox is choked with hundreds of megabytes of redundant attachments. Plus, if you weren't cc'd on the message, you won't be part of the conversation.

One would like at the core of dotWRK a repository of all such work-related data. The ability to freely organize and associate the work products into meaningful hierarchies and structures is what will make the system powerful. Ideally, revision control would be automatic and nearly transparent. We shouldn't make any assumptions about the formats that these work products will use, nor the tools used to author and interact with them.

An excellent resource for motivating this design is just about everything written by Jon Udell, especially his excellent and overlooked book: Practical Internet Groupware.

6: Re: [dotWRK] what it should become - part deux (response to 4)

Posted by Jade Rubick on 04/14/03 11:37 PM

I like Jeroen and Roger's ideas here about work products.

For example, our company has a lot of information that we want to keep associated with a project.

In the same way that Outlook has a lot of different types of information that can be viewed throughout the inbox, I think a project should allow you to associate:

- queries on tables (our company would like to associate each product with a project, for example -- so we'd like to see a list of products in each project page).

Perhaps there could be some sort of a service contract for items that are viewed on the project page. They have to implement a certain function or something, and then they'll automatically be included on the project page...?

Forum OpenACS Development: [dotWRK] what it should become - part deux