Thursday, August 05, 2004

DeskLog, part 3

User interface design for ProgrammersPete had some good feedback on my DeskLog post from a couple of days ago. His remarks are in bold with my responses interspersed throughout.

I don't understand your email accountability retort. Yes a person can ignore their e-mail inbox, but they could also ignore their desklog too. In either case the driver of the work item would know the person received the message. Unless you put in some access controls that don't allow someone to manage (ie delete) items in their inboxes, they would always be able to claim they accidently deleted it.

They could ignore their desklog, but the difference is - it's transparent to the rest of the world. Say I needed you to approve or deny a request for an Aeron chair. The request can not be deleted. It's either in your inbox or your outbox. Either way, everyone (including me, the requestor) can see whether you've gotten to it or not. They can't read the text of the request, but they can see the title. They know how many items are in your queue. So the differences between email and DeskLog are simply accountability and transparency.

I don't think a simple hierarchical trust relationships would suffice.. Who I need to work with doesn't alway fit my reporting structure.

That's true. However, I do know most large organizations (even if they're matrixed) still have an ostensible, hierarchial manager (and sometimes, for senior folks, an administrative assistant). And, in fact, the LDAP standard schema for inetOrgPerson - supported by many Fortune 100 companies - has one attribute named manager and one for an admin. These relationships are based upon RFC-standard schemas and are used for great effect in org-charts, workflow, ad hoc reporting, etc. by lots of third-party products. I envision DeskLog as just another third party offering supporting these standards.

Would this 'inbox' be an aggregate of e-mail and desklog stuff? If so there are some prickly privacy issues to deal with.

Nope. This is a virtual inbox and outbox dedicated to DeskLog. There are no privacy issues - this is a work-related application and only you (and, perhaps your hierarchical managers, if the product has been installed that way) can see the contents of the file-folders in the boxes. Everyone else can see the folder titles, senders, dates, etc. - but can't see the contents.

Let's assume my desklog inbox contain only desklog work items. Does it aggregate items from all the projects I'm working on or do I have multiple inboxes? If it's an aggregation why would I want people from one project seeing my other work items.

Good question. You probably don't want them seeing everything, but they will. There might be some simple forms of categorization, a la Gmail. There will be a search box, so you can find items that you're interested in. But, just like the physical inbox on your desk, you get one 'pile'. It's up to you to shuffle them, prioritize them, label them, but... it's still one pile. The whole idea is transparency. Wouldn't it be neat that -- before you submit a purchase requisition -- you can see that the person who handles the reqs has a backlog of 100? And her desklog blog section says she's on vacation? I think so. I might just charge the item on my corporate card and file an expense report. Again, the transparency is the key. It's like walking into her office, seeing that she's not there, and that there are 100 file folders in her inbox. It's the virtual equivalent of that.

On workflow products, the only one I've used is the venerable Notes/Domino. People use it all the time to build less general versions of the workflow apps such as desklog. In fact, I believe you could do all of what you describe and with better security using Notes/Domino today.

Probably true. The only really large organizations with Notes (e.g., between 15,000 and 100,000 seats) I'm familiar with don't use it for workflow. They use it for email only. Never really asked why. Probably complexity, training issues or something like that.

I envision this as a stand-alone offering that leverages existing standards (e.g., SMTP/POP3/IMAP for email notifications), LDAP for retrieving user attribute info, HTTP for delivery of the pages.

I hope to have some mockups of DeskLog up this weekend.

No comments: