So in looking back over that last few entries, it seems I have strayed from my original mission, which was to cover issues regarding informatics and how it relates to science. The first part seems to have dominated the posts recently, so I am dropping all pretenses starting a new blog, over at Blogger competitor Wordpress.
Why a new platform? I figured I would give Wordpress a spin to see how it compares to blogger. Also I like the template they had for the blog ;) So far, the interface is similar, but looks a bit cleaner than Blogger's. Overall, it seems the same functionality and workflow, with the addition of one thing that I can see coming in very useful for a site like I envision, permanent pages.
In effect, If I write something that I want to be prominently displayed at all times, I create a page. This can come in handy say, if I give a set of instructions for setting up your development environment, or for providing a listing of resources. As a regular blog post these types of items are "discoverable" by searching, but they will eventually go away as new posts drown them out.
Another agument for the Page as opposed to a post is to combat a post from becoming stale. How many times have you thought you found an answer to a question in a blog post but it turns out said post is a bit old and the solution no longer applies? I guess stackoverflow seeks to remedy this, but bloggers can do their part by posting "important" and generally applicable posts with prominence as a page, thus they are always reminded to update it, since is it always visible.
Anywho, there I go again, talking strictly about web applications. Well, I guess I'll shut up now and you can check AppMecha for more posts related to these issues.
Showing posts with label application design. Show all posts
Showing posts with label application design. Show all posts
Monday, October 6, 2008
Thursday, March 13, 2008
Twitter is killing my blog
Twitter is killing my blog initiative. In fact this post can just be a straight copy-paste from some recent tweets (reverse chronological order):
Really? It's that easy? Can you beat that ease-of-brain-dump blogger.com? I think not. Some picasa functions came close for posting quick notes on photos, but there isn't really a native blogger equivalent (that I know of). The whole create post -> edit post -> post post life cycle is too long for a quick set of thoughts you want to jot down.
I could probably research this more, but really why would I when twitter is always there, and I actually have an audience that comments back to my posts. And so back to my original point: Twitter is killing my blog.
 | delagoya Ah, just saw that on XP you can't see my character cleverness. Sux4U dude about 23 hours ago from Snitter   |
| | delagoya suppose a hash assignment {:foo ➠ :bar } about 23 hours ago from Snitter |
| | delagoya and also wondering if I can use ruby's syntatic suger with random windings about 23 hours ago from Snitter |
| | delagoya It's like the evolution of large emails ☞ short emails ☞ IM about 23 hours ago from Snitter |
| | delagoya notice that twitter is killing my blog initiative. Why blog when a short tweet will do? about 23 hours ago from Snitter |
Really? It's that easy? Can you beat that ease-of-brain-dump blogger.com? I think not. Some picasa functions came close for posting quick notes on photos, but there isn't really a native blogger equivalent (that I know of). The whole create post -> edit post -> post post life cycle is too long for a quick set of thoughts you want to jot down.
I could probably research this more, but really why would I when twitter is always there, and I actually have an audience that comments back to my posts. And so back to my original point: Twitter is killing my blog.
Monday, October 1, 2007
ITMArT : Design : Part 1 "The competition"
So far my posts have focused on the bencher's quest (to learn code). This is mainly because it is infinitely easier to write about small and helpful scripts than about complex issues like application UI design. But since I introduced the ITMArT application, I might as well go through the design process for it. This will be a mutlipart post covering a couple of areas of the application and design process. First up will be the history and requirments of the app.
History
ITMArT began as any project does:Outlining a set of requirements and then looking to see if some existing application already does what you want to accomplish. In this case, the requirements consisted of:
You'd think there would be some open source ERP system out there that would have these component in it, and there are: Openbravo.com and TinyERP are just two examples. The trouble is that ERP systems generally tend to focus on the needs of the business processes and not so much on the requirements of the end user. I'll get to what that means in a minute, but suffice to say this type of focus would not have worked for us.
The ERPs
Let's first look at Openbravo, a Zope application and UI nightmare. Pop-ups all over the place, difficult navigation and difficult to use forms. Tons of click-through dialogs and switching between keyboard and mouse, essentially MSDN design taken to the web. But don't just take my word for it, demo it yourself and see.
TinyERP is much better, but still focuses on the business case. For instance their forms (and top menu) make a distinction between creating a purchase order and creating the line items for that order. Which means that the user must know ahead of time that they need to create an order request first, which means that the system is not intuitive enough and will either require documentation (which no one reads) or training (which you have to pay for). Much worse, when creating the order line items, you need to specify a ton of fields and know the purchase order ID! OK, so the AJAX search helps you out for finding the order ID, but one typo and you have a clean up on aisle 9.
The last thing that makes an ERP unsuitable would be my first point, namely the focus on business processes. Usually this is not a problem, since you can make the assumption that the community is relatively stable and business oriented. The user community we have to service is a mix of bench scientists, admin assistants and business office types. There are no resources for training and the usability expectations are high.
This means that we have to shoot for the Lowest Common Denominator in terms of the overhead placed the ordering process. Making a purchase request should be as simple as creating an email, and if it is not, then there had better be some work savings later to make up for it. Order placement in TinyERP is less than ideal, but not completely onerous as Openbravo, and the work savings are that the reporting, catalog searching and order processesing are streamlined.
The deal breaker comes in the catalog management aspect. Adding items and vendors is not intuitive or easy enough for the majority of our user base. This is where focusing on the business process of catalog management really takes a pounding on usability. The central assumption here is that catalogs come from a preferred set of vendors and are bulk updated (and not very often). The broad user community means that the vendor list will be constantly changing, that pricing will be variable, and the various catalogs will be fluid. The burden of catalog management must be passed on to the purchase requester for the application to be scalable (e.g. roled out to other departments or laboratories). Centralized management of the catalog would incur too high a cost otherwise.
Conclusion
Based on these quick reviews of existing systems, I decided that further trolling through open source projects would not be worth my time. If even a simple, easy, and good looking application like TinyERP did not fit the bill, what would? A custom application, that's what.
On the next ITMArT post, we'll dicuss the actual design choices made to fulfill the list of requirements that we had mentioned at the start.
History
ITMArT began as any project does:Outlining a set of requirements and then looking to see if some existing application already does what you want to accomplish. In this case, the requirements consisted of:
- an application that tracks purchase requests and purchase orders
- users would often have recurring request, a searchable catalog would be ideal
- new types of requests come up often so adding vendors and items should be easy and flexible
- orders can only be placed by select group of users with access to funds
- monthly report of expenditures would be great
- email alerts of requests from request to order to receiving
You'd think there would be some open source ERP system out there that would have these component in it, and there are: Openbravo.com and TinyERP are just two examples. The trouble is that ERP systems generally tend to focus on the needs of the business processes and not so much on the requirements of the end user. I'll get to what that means in a minute, but suffice to say this type of focus would not have worked for us.
The ERPs
Let's first look at Openbravo, a Zope application and UI nightmare. Pop-ups all over the place, difficult navigation and difficult to use forms. Tons of click-through dialogs and switching between keyboard and mouse, essentially MSDN design taken to the web. But don't just take my word for it, demo it yourself and see.
TinyERP is much better, but still focuses on the business case. For instance their forms (and top menu) make a distinction between creating a purchase order and creating the line items for that order. Which means that the user must know ahead of time that they need to create an order request first, which means that the system is not intuitive enough and will either require documentation (which no one reads) or training (which you have to pay for). Much worse, when creating the order line items, you need to specify a ton of fields and know the purchase order ID! OK, so the AJAX search helps you out for finding the order ID, but one typo and you have a clean up on aisle 9.
The last thing that makes an ERP unsuitable would be my first point, namely the focus on business processes. Usually this is not a problem, since you can make the assumption that the community is relatively stable and business oriented. The user community we have to service is a mix of bench scientists, admin assistants and business office types. There are no resources for training and the usability expectations are high.
This means that we have to shoot for the Lowest Common Denominator in terms of the overhead placed the ordering process. Making a purchase request should be as simple as creating an email, and if it is not, then there had better be some work savings later to make up for it. Order placement in TinyERP is less than ideal, but not completely onerous as Openbravo, and the work savings are that the reporting, catalog searching and order processesing are streamlined.
The deal breaker comes in the catalog management aspect. Adding items and vendors is not intuitive or easy enough for the majority of our user base. This is where focusing on the business process of catalog management really takes a pounding on usability. The central assumption here is that catalogs come from a preferred set of vendors and are bulk updated (and not very often). The broad user community means that the vendor list will be constantly changing, that pricing will be variable, and the various catalogs will be fluid. The burden of catalog management must be passed on to the purchase requester for the application to be scalable (e.g. roled out to other departments or laboratories). Centralized management of the catalog would incur too high a cost otherwise.
Conclusion
Based on these quick reviews of existing systems, I decided that further trolling through open source projects would not be worth my time. If even a simple, easy, and good looking application like TinyERP did not fit the bill, what would? A custom application, that's what.
On the next ITMArT post, we'll dicuss the actual design choices made to fulfill the list of requirements that we had mentioned at the start.
Friday, August 17, 2007
ITMArT: A request tracking system
For a few (3-4) months I have been working on a user request and order management tracking system. Most of that time has been spent wrestling with RoR's ajax functionality and making the UI as intuitive as I possibly can. Basically I took the "getting real" book at face value and started with the interface.
What remains, though, are lots of "under-the-hood" plumbing to get small things like getting user accounts to work with the CAS SSO server, access control lists and group management. Oh, and email alerts... yeeesh. Well at least it looks pretty.
The search works well and the cart concept seems to be pretty easy to follow. The order processing, though, still leaves something to be desired. Reporting is air-ware at the moment.
I'll keep posting tidbits about this project often (since it currently take 90% of my time) so stay tuned!
What remains, though, are lots of "under-the-hood" plumbing to get small things like getting user accounts to work with the CAS SSO server, access control lists and group management. Oh, and email alerts... yeeesh. Well at least it looks pretty.
The search works well and the cart concept seems to be pretty easy to follow. The order processing, though, still leaves something to be desired. Reporting is air-ware at the moment.
I'll keep posting tidbits about this project often (since it currently take 90% of my time) so stay tuned!
Subscribe to:
Posts (Atom)