18 Jan 2005 | nick said...

I've noticed that with the handful of weblogging tools I've used recently, creating a new post is either one click away or there when you start. Nice if you know what you're going to write, but I never do. I kinda miss being forced to look at what I've talked about recently... But it makes sense for most people.

Everything else, especially online banking type stuff, I've had trouble getting anything into or out of the interface. It's usually go to site fail browser sniff go to home page log in a start page offering me the option of doing all kinds of things I would never do figure out what convoluted heading covers what I do want to do drill down a few levels get some sort of server error.

18 Jan 2005 | Robb Beal said...

The HTML web isn't a direct manipulation environment. The lack of a grid and canvas controls, both without strong distinctions between view and edit modes, are the most striking omissions when compared to the desktop.

Another glaring omission is object selectability, especially the ability to select disparate objects and subsequently do something interesting with them.

There's a lot of work left to do!

18 Jan 2005 | JD said...

In response, I created post on my blog. Here's excerpt:

--------------------------------------------------------------------------
Jason, from Signal vs Noise, wonders why Web Apps are concentrated more on data viewing rather than data input.

Heres what I think:

1. An app, whether desktop app/web app, requires data entry in particular format at particular location. For Desktop app you noted, i.e. Word and Photoshop, they have a clutter free location (a blank document) opened automatically (in case of Word) or you can open it using a short cut like Ctrl + N (A blank canvas, in case of Photoshop) I think only OneNote is an application, where you can type just about anywhere on screen and application accepts it easily (and I love that feature!)!

2. Depending on App, you have to specify some input before you can work on it. E.g. in Photoshop, you have to specify Image width/height, resolution etc. before you can work on it. Things get little easier for Desktop App, because default values presented by Photoshop are most of the time good enough. [Photoshop remembers size of last image you edited OR if you have an image copied on clip board, selecting Ctrl + N will open dialog with size which is same as the size of image on clipboard.] My conclusion: As Desktop apps are RICH (feature wise/response wise), they feel less tedious. As Web apps are generally not rich and as responsive as Desktop, they make you crawl.

3. Again Richness of Desktop Apps allows it to take user data in ANY FORMAT and quickly convert it into format which is compatible with application. If you have used Outlook, you might know that ................

Read rest of it on my post.

18 Jan 2005 | Mike D. said...

The difference to me is that the web is primarily a consumptive medium. Even from its beginnings, it was more about sharing information than creating or inputing it (hence the term web browser). It wasn't until the creation of the TEXTAREA field that much direct input even took place on the web. Native apps on your OS, however, seem to be more about creation. Word, yep. Photoshop, yep.

I've heard stats that say most people consume anywhere from 10 times to 100 times more than they create online... depending on how much webmail they send. If this is true, it makes sense to keep a bias towards a reading interface, but you're right... when you're in *obvious* creation mode on the web, your interface should react accordingly.

18 Jan 2005 | Phil Boardman said...

I use WordPress. I click 'login', enter name & password, then start typing. Something with WordPress that would be better is for the action after entering the data to be to view the data you just entered rather than showing a 'blank slate' again.

18 Jan 2005 | Jef Minard said...

The primary reason the chain follows:

pick an object → new screen → click the link to add a new item → new screen

is the way that authors build up their databases.

It's easier to deal with data moving around when you know where it's going, as opposed to having this amorphous mass of data that you are supposed to juggle in a stateless environment. (As opposed to Photoshop which doesn't have to worry about you "refreshing" the whole application)

18 Jan 2005 | Lynn said...

A very simple webapp for writing notes into would be cool.

At the moment I don't blog from work because of the interface thing, it just seems too cumbersome - I'll write something, leave it for a while because I'm thinking about it, or taking phonecalls, or whatever, and then the system freezes etc or I just lose interest in what I'm trying to write. Also what I'm writing is definately notes, not really something that I want to put up on my blog.

So what I do now is write into a html template I've got in Notepad, I save the file at the end of the night, load it to my website through BaseCamp. Then in the morning I go into Blogger and do a proper blog post about whatever, and also make a link to the notes from the night before.

It's rather convoluted, but it means that I've got a light interface for making notes, that I can decide not to publish, and which I've got access to later on down the track.

18 Jan 2005 | Rimantas said...

is the way that authors build up their databases.

This is the problem with most software/software driven products -- they are built upon implementation model, not upon user's goals.
It is easier to implement this way, but it is harder to use then.

Better to put some more effort into design/implementation and get
easy to use product.

Talking about web-apps this is where GMail stands out -- far from the perfect, but still -- it is UI not 1000MB of storage that makes this webmail different.

How about "reply" feature in GMail -- you always have reply box under the message you read, so in case you want to reply you just move cursor into it (it then expands to show more info/options). This is better than any desktop email app I've used, they all want to open new window (which is bad). GMail gets some other stuff right too, but that's another story.

18 Jan 2005 | james said...

I helped build a site management system like this one time. The client could enter their data first and then decide where to put it later. It ended up being more clicks to actually do something with the data. Also, it was difficult to come up with an interface for them to move items around on the site. How do you represent a site hierarchy in html form elements other than a select field with indented options?

18 Jan 2005 | Darrel said...

Wordpress offers that instant log-in, enter a post.

That said, I think it's an orientating issue. The initial view of current content is important to figure out where you're at in the data space. Expecially with web apps...I find that few folks can really grasp their own site/content structure.

As for desktop software, I'm actually noticing a trend towards this model as well. If I open Dreamweaver or VisualStudio these days, I get an overview of my 'projects' that I need to navigate through to get to my work-in progress. Most of my production software these days allows me to save my workspace so upon each launch I'm back to where I left off...in 'data view' mode.

I often work this way in the OS as well. I'll make a new document in a directory via the OS, THEN open it to enter data.

18 Jan 2005 | Wilson said...

When you open Word, you've decided you're going to create a certain type of object, a document. Likewise for Photoshop, etc. When you're done, you can save (or export) the fruits of your labor in a variety of formats, but they are all limited to the type of object you decided to create in the first place by opening the application.

Most web apps (including Basecamp) are designed to manage multiple types of content. Each input screen is designed to ask the right questions and encourage you to input data that is appropriate to the context. This is arguably one of key advantages of a content management app in the first place, over a more flexible input tool (like Dreamweaver, or Notepad). The tool itself knows what kind of information you want to enter, and encourages you to input consistent and appropriate information.

Desktop apps tend to me more focused on a dedicated task. Even with desktop apps, you've already logged in (new screen), chosen an application (new screen), chosen to add a new document (new screen), and started typing. It just doesn't happen all at once, like when you log in to your blog admin, then into your projects admin, then into your webmail, and on and on...

18 Jan 2005 | Rob Sutherland said...

Since most Web apps (or any data-entry application) requires data to be formatted in specific ways it is hard to start with a completely blank slate.

I noticed this problem a while back and for some of the more commonly used (and less data required) apps starting combining the interfaces. the left of the screen show the 5/10/20 most recent posts and the right side of the screen provided the data entry fields. The client seemed to like this and while it added some complexity to the interface it made it quicker if not easier to use.

18 Jan 2005 | Marc Escobosa said...

It seems to me this discussion is glossing over some rather important distinctions between various types of online applications and their correspondent requirements for ease of editing.

For one, there seems to be an assumption that editing information should be as easy as possible. There are many situations where this is explicitly not the case. Most notably in situations where the information is controlled data and editing it requires access privileges. But even if the information is open to everyone, in situations where many people are sharing information with each other and no one knows what everyone else knows, it can be very dangerous to allow "direct editing" when it is not clear what they are actually editing.

But it's made worse by the fact that the web platform handles "undo" functionality in a very fractured manner unlike desktop applications. Online, the browser and the application have their own somewhat disconnected senses of what undo means and often getting a web application to properly support multiple undos is impossible. (Especially when you have multiple people editing the information simultaneously in which case multiple undos become a technical quasi-impossibility.)

So while I would agree with the premise that apps should be keyed off quicker access to editing for tasks like manipulating your email or jotting down personal meeting notes, I just don't think we should draw some universal axiom on this yet for all application types.

18 Jan 2005 | Michael said...

In certain applications where user input fills out the content of a page, and that content is updated at least weekly, I think it's very important to make the Add function very prominant and easy.

I'm working on a project that includes many standard View and Add functions. We've decided to place an Add box above every View box, when appropriate. The Add box isn't 100% - meaning it shows only the first 1 to 3 prompts of the item to add. Clicking Next brings you to another screen that allows you to fill out the other prompts. On submission it returns you to the newly updated View box, with the Add box above it.

It flows well. The View box serves as a confirmation and work with area - you can ensure the right stuff is there and manipulate it easily. The Add box above screams "Use me because this is how the page will get content!" Otherwise the user may feel lost on a blank page that includes a small, discreet add icon in the bottom right.

18 Jan 2005 | Ryan Platte said...

What about using email to enter new content?

I just had a client complain to me about Basecamp for the very reason you cite: too cumbersome to communicate, especially when all we wanted to do was simply reply to each other. We've reverted to email correspondence.

Email is something the customer is accustomed to, and its formatting conventions are the lingua franca Textile and Markdown both draw from for intuitive ways to translate plain text to HTML.

It seems odd that Basecamp shouts DO NOT REPLY on its email notifications, when it would be so natural to do just that, right from the program I'm using at the time.

Are you familiar with RT, the Perl-based request tracker? It creates a strong link between email threads and extra features available via the web. It's well thought out -- email is the primary mode of communication, but there's a delightful web interface as well. URLs can be included in every message to see additional context and other features on the web.

18 Jan 2005 | JF said...

It seems odd that Basecamp shouts DO NOT REPLY on its email notifications, when it would be so natural to do just that, right from the program I'm using at the time.

The problem with using email is that is decentralized. There's no place to get brought up to speed (for new people) and no record of someone when they leave. Everyone's inbox is different. Replies are messy, deeply quoted, etc.

Email or IM is great for quick communications -- and we use them all the time instead of Basecamp -- but the serious stuff is much better centralized, archived, and tagged for accountability.

18 Jan 2005 | JF said...

And, FYI, we have some new email integration features planned for Basecamp.

18 Jan 2005 | sloan said...

One concept we tried to implement on a conversion of a client server application to web was the Super Sticky. It was simply a place to type notes that was always accesible and automatically tagged itself with some basic information like time and date. The idea was to get the person using the tool before worrying about where it's information would go. Then it could be tagged more extensively once the user was done with their "real" work and turn it into a meeting note, phone call, the beginning of a Word document, an email... whatever. It was better than a basic sticky application because it could be accessed from any machine and was always available. Of course... this was killed off...

Just look at anyone's desk... there are usually stickies, notepads, PDAs, phones, all sorts of tools being used to basically store simple pieces of data and yet it is all randomly spread out across their workspace. It is possible to develop a software object model that could implement this idea without tying it to one specific application.

18 Jan 2005 | Lite said...

Sounds like you have been interacting with a lot of CMS's (or CM-Mess as we used to call them)

Yes, this is a very programatic way of working with data, but needed in the controlled world of content management and enterprise-grade systems.

Imagine in a newsroom if you had 200 people hitting a system with the "create first, then file" model. you would have a database that would get HAMMERED. In this case, the sequential (i.e. conventional) way of CM works fine.

It's almost as if you want to bypass some if the needed interaction points, definitely a trait of the "me generation" (we want it now!)

See ya next login!

18 Jan 2005 | Lee said...

Email or IM is great for quick communications -- and we use them all the time instead of Basecamp -- but the serious stuff is much better centralized, archived, and tagged for accountability.

Then why not add the contents of the reply to the Basecamp reply list, so it is archived, tagged, and centralized?

18 Jan 2005 | JF said...

Then why not add the contents of the reply to the Basecamp reply list, so it is archived, tagged, and centralized?

We are working on this. It's a lot harder than just saying "let's do it!" ;)

18 Jan 2005 | Alex said...

Textpattern lets you "write first, then decide where to put it." After you login, you go straight to the "write" page of the "content" section. I like it.

18 Jan 2005 | seth said...

On the basecamp/email issue...

I have a friend who wrote a .NET application that did just that. Took information from email and entered it into an intranet-project-management-type-system. It isn't a trivial task, but I'm glad you guys have finally started working on this.

I've had most of my clients just opt-out of Basecamp and revert to email for communications.

18 Jan 2005 | sloan said...

Um, if a database can't take 200 hits at once then the database needs some work. If it is a newsroom with 200 people that need concurrent access they need a hefty system anyway. A database might not be the answer before it is filed, maybe its XML file storage until then.

"It's almost as if you want to bypass some if the needed interaction points, definitely a trait of the "me generation" (we want it now!)"
Needed interaction points? What piece of paper requires you to file it before you use it? That's the beauty of paper. Wanting something WHEN you need it without unnecssary steps isn't being selfish or unreasonable.

A major problem with designing is that we bring our own baggage to the design. We make assumptions that we don't have to make.

18 Jan 2005 | Web Design Dustin said...

I agree much of these things can be very difficult. Great post Jason! You are very smart!!!

Web Design Dustin
Webdesign Company Jacksonville Florida

19 Jan 2005 | lee said...

We are working on this. It's a lot harder than just saying "let's do it!" ;)

That's good news. We use FogBugz for bug tracking, and it's able to access a POP account on a regular basis to read in any e-mail replies to a bug report by a client, identify the bug that the e-mail is about, and add the contents to its comments thread. It's very convenient to be able to have a conversation with a client via email, and have the whole thread recorded permanently in the same place as the relevant bug.

19 Jan 2005 | Gil said...

Sounds like Whiteboard might be released soon...

19 Jan 2005 | Larry Burningham said...

Its is very simple why web apps are built this way. Web apps are usually built for the lowest skilled user. This is viewed as good user centered design. This often takes the form of hand holding by stepping the user through each part of the process.

On the flip side an application assumes that the user already has an enhanced skill level or is very unforgiving if you don't. For instance, using Photoshop is a very explorative process because you are given a set of tools, a blank canvas, a million options and absolutely no direction. Think about how you use Photoshop. I use it to batch photos, crop and auto adjust. But I no nothing about Channel Operations or why I would use them. And guess what adobe isn't going to walk me through it.

Why, because these applications assume you have the knowledge or you will buy a book.

Web apps do the exact opposite. They assume you are an idiot and will most likely get frustrated and call if you can't figure it out quickly.

I have seen this in action. I had a programmer with little interface experience build a product catalog admin for a client. On one screen you could update all the parameters of a product and apply any of all of these changes to the entire product category if you wanted. Brillant! Except the end user would want to update a single product and would of course inadvertenly apply it to the whole category. Even after rounds of training she still did not get it and she is intelligent! Now the admin steps you through each part of the process and even asks you to confirm.

Jason you are right, but there is no way the masses will comprehend the paradigm shift. 1984 is still 1984 (just with more options).

19 Jan 2005 | sloan said...

Sounds like the web app breaks basic rules of usability such as confirmation of an action that is not reversible. You say that web apps are designed for users that have little skill and I would say exactly the opposite. You fill out a form and accidently hit the close window widget... what happens? You lose all of your work! Compare that to a standard application. You have to use three different technologies in order to get basic usability into a web application: HTML, CSS and JavaScript... and support varies from browser to browser! So what happens? Designers have been subconsciously trained to DO LESS usability with their web apps than what they should! It is a constant battle to challenge your assumptions and really push the development process to produce a truely usable application. I get yelled at all the time for asking for too much... isn't that ridiculous? The bar for usability has been set so low on the web (which isn't surprising because it was meant to be easy to create and not meant to do what it does today) that we might have trouble seeing it.

19 Jan 2005 | Ben Brophy said...

I think javascript bookmarklets are really soltuion in some cases. I try to build in that functionality, and then add it to my clients bookmark bar for them. Then they click a bookmark ("add wish" for example) and are right where they need to be. I'd love to have some basecamp bookmarklets, actually...

19 Jan 2005 | JD said...

I have posted some more thoughts on this on my blog.

Copy:

This post is in continuation with my earlier post about Default Actions for Web Apps.

Anyone who has used a complicated Web Application will agree that it can really get tiring to click on so many links just to access a particular option or perform an action! The problem is severe if the Web Application is slow. What could be the possible solutions?

1. Default page upon login should correspond to the main action for which user is using the App. E.g. for Blogging software Admin page, main action would be to write a new post. So, it will make sense to have Write Post as default page upon login. Now, not every applicatin is as black and white as blogging software admin page where default action is obvious. So, in an ideal situation, user of the application should be allowed to choose the default page. [We see it all the time in desktop apps, where they have checkbox to make selected options as default options for given action. ]

2. Second and more useful feature a web application can provide is Recently Performed Actions and Most Frequently Performed Actions. It should be relatively easy to code Recently Performed Actions feature. Though, it will take some effort to code Most Frequently Performed Actions as you have to monitor user action for some period of time. But both of these can be real time saver to users and I think it is worth Development effort to code these features. Amazon, eBay and other sites already implement Recently Viewed Items feature and I think its extremely useful as it has saved me search effort a number of times.

What do you say?
JD

19 Jan 2005 | sloan said...

Recently Viewed is a bit different than Recent Action though. An action has both a subject and an action. Having a list of actions means what? Preform the same action to the same subject again? Does an action grey out if it cannot be applied to the current object? I understand the intent, I just don't know if it can become a logical construct. Office had that default state where only the most recently used items appeared by default in menus and it drove people nutty... Maybe making the actions more easily available for the _current_ situation is the more viable option...

The problem of having to click on multiple links to preform and action or change an option probably has more to do with the design of that system than what is possible. Of course, with how much "application" work that is happening on the web why don't we have the ability to control the browser menu bar? Create your own bar that is part of the browser window itself and put your commands there... Put a "web page" menu item before File and Edit that the page can control. THAT would be nice! There's plenty of room in that bar!

26 Jan 2005 | Don Schenck said...

Everything's a "web app" nowadays.

I thought Java was supposed to cure that problem. You'd write once, deploy everywhere, and have thick clients all over the place.

So much for ideas ... *sigh*

29 Jan 2005 | shpetim said...

halo hej i am for gjilan