Posts in Category "Opinion and Rants"

Why HTML forms are [still] important

Web designers have access to countless rich media tools and social applications, why should they still care about the humble form?

How customers interact with you

Think about the last dozen web sites you visited. How many asked you for information? Whether it’s an account registration, a comment on a blog post, a web forum or a survey, chances are there was a form to gather your information.

HTML forms are important components of modern websites. It’s how your customers tell you who they are, sign up for services and purchase your products. They are the major way your users communicate with you.

If you are truly interacting with your web site’s users you will need to gather some information about them at some point and most of the time this is done through a form.

But people hate forms

So why haven’t HTML forms gotten the attention they deserve? I blame much of it on crappy design and inappropriate use. There are some of nice tools out there that make creating HTML forms easy, unfortunately the forms created with these tools is often not well thought out.

Badly designed or badly placed forms can cause user frustration, taking them out of the web sites experience. One of the worst examples of this is the popup survey. If I’m reading your site trying to find a recipe for the ten pounds of zucchini that are in my garden, I don’t want to fill in a survey about your new credit card cross promotion.

Regardless of your form there are some basic things that you should consider:

  • Context – ask for the right information at the right time. Sure you need the customer’s shipping address, but ask for it at the right time (and pre-fill it if it’s a returning customer).
  • Functionality – the form should work as users are expecting it to. I know it sounds silly, but there is no easier way to lose audience than to fill in a form and not have the submit button work (or worse have it reset the form).
    This also means you should follow the standard conventions for forms. For example; if you are providing an exclusive choice, use a radio button and not a check box. When users see a check box they assume that they can choose multiple items.
  • Security – Your gathering, potentially sensitive, customer information. It is extremely important to ensure that that data is handled appropriately.
  • Design – This is far too broad a subject for this one post, but needless to say you should give the same consideration to form design as you would any other aspect of the site.

Think small

The vast majority of web based forms are simple, with only a handful of fields. By no means are these insignificant, the data gathered here drives the customer experience for many web sites.

In fact, I would argue that these are more important as data gathering devices than the large complex forms, at least it terms of web design:

  • They are completed more often. People are more inclined to fill out a four field form than a four page one.
  • They are easier to build and update. Less complex forms are easier to put together and deploy, meaning that there is a better chance that they will see the light of day
  • The total amount of information gathered is several times that of complex forms. Think of all of the little bits of information you are asked for in the course of a day.

Your Thoughts

What are your thoughts?  Do you feel that HTML forms have a place in the modern web design toolkit?  Is your organization using HTML forms to interact with your audience? 

 

Completely unrelated side note:

A few of you may have noticed that I have changed the name of this blog from “Steampowered” to “Enterprise…I Think”.  There are a couple of reasons for this:  1 – To avoid confusion with another web site. 2 – My role at Adobe has recently changed and the change in the blog’s focus will reflect that change.   Cheers,  Mike.

Customer Experience Management for the Pragmatist

As you may be aware, the term Customer Experience Management (CEM) has become one of the latest buzzwords in the enterprise software industry.  Many large companies have formed CEM groups and a few have even created “C” level positions that are dedicated to improving the customer experience.  Adobe has embraced CEM in a big way (you can see the Experience Delivers blog  or Steven Webster’s blog for just a couple of examples), so I felt I needed to understand more about it.

In my search for answers I came across tons of white papers, research notes, videos and other content on CEM and its related topics (such as Rich Internet Applications (RIA), User Experience (UX), Experience Oriented Architecture (XOA), etc.).  There were web pages that call out “bad” design and praise “good” design.  Some sites had some best practices (although these were mostly based on specific examples).  I found a plethora of other phrases that seemed to float around the subject – customer oriented design, put the customer first, contextual design, etc.

I also spoke with some of Adobe’s CEM proponents.  Unfortunately these conversations tended to bend towards rather philosophical discussions.  One time someone actually said “the Medium is the Message”.    At this point my the part of my brain that performs cognitive reasoning ran down the hallway and hid in a quiet corner.  I can’t help it; McLuhan has that effect on me.

Nothing really hit home with me.  I might be able to recognize a CEM application if I saw one, but I still couldn’t describe to you why it was CEM.

It started to feel like when I played baseball as a kid.  Both my little league coach and my dad kept telling me to “keep your eye on the ball”.  Repeating the phrase over and over made it essentially meaningless.  One day someone (probably a frustrated first baseman) said something like – “look, just watch the ball as it leaves my hand.  Keep watching it as it goes through the air and then put your glove in front of it.”  All of a sudden it made sense.  I still suck at baseball, but at least I don’t get beaned as often.

One day, while searching for cheap vacation flights, things started to congeal.  Navigating through several sites that essentially did the same thing, I started to understand what was meant by customer experience.  More importantly I started to get why it was so important.

When you get right down to it, what does CEM mean in a practical sense?  Its simple really – build software that helps the user accomplish their goal.  At the very least it should not actively make the user mad.

Like so many simple statements, that has some rather complex consequences.  For one thing, as a designer/developer you really need to understand what the user is trying to do as well as how they feel confortable doing it.  This includes not only understanding the direct path to the goal, but how to assist them.  Also allow people to get back when they go down a different path.

If I look at my own recent experience with online ticket retailers, there were precious few who designed their applications in this way.  For the most part the sites were designed for people to book flights; but I, for one, wasn’t using it that way.  I was shopping for flights – changing dates/times, departure location (I’m Canadian, so it sometimes pays to drive to a US airport), airlines, etc.  One site made me re-enter all of the information each time I changed one thing.  Others would only give me one flight choice and would not suggest others.  Some would require me to know things that are industry specific (such as airport codes).  The sites I really appreciated, and therefor spent more time on, made my life easier.

Here are some general things that I observed:

  • Cut down on the clicking
    • If you’re going to require me to read something then just show it to me.  Don’t make me click on a button that brings it up.  If its that important than gimme it.  This really goes to presenting the right information at the right time.
  • Get on with it! (or where’s the “f@*ck off” button)
    • Of course the flip side is presenting too much information.  If I don’t need it right now, get rid of it.
  • Just do what I tell you to do
    • Software is a tool.  As developers we often think that the software itself is the most important thing.  We must keep in mind that the user is trying to get something done (like shop for a flight) and the software is just a means to an end.
  • I don’t care about your process
    • Remember that the user is not concerned with what is going on behind the scenes.  Your product codes, industry regulations, inter-departmental routing, etc. does not matter to the user.  While you do want to tell the user what is going on, they don’t need to know what’s going on in the sausage factory.
  • Customize when necessary, but but not necessarily customize
    • There is a trend to allow the user to customize every aspect an application.  In some circumstances this is a really nice thing (iGoogle is a prime example), but it has a dark side.  I’ve used too many applications that require lengthy configuration to provide a personalized experience.  I know they theory is that by customizing the interface the user takes ownership, but Its not always necessary or even wanted.  Sometimes I just want to do a quick search and get on with my life (google.com is a prime example).

As I said, it all boils down to designing software that helps the user do something.

Creating an Organized Mosaic Project Structure

Lately, I’ve been working a lot with people that are new to LiveCycle ES2 Mosaic.  One thing always seems to come up is the question of the best way to organize Mosaic projects.    There aren’t any hard and fast rules (with the exception of the Catalog folder layout), but I’ve seen enough similarities in unrelated projects to suggest that there are some unofficial conventions that are forming.  I won’t go as far as to call the following “best practices”, rather consider them suggestions based on experience.  When combined with standard Flex best practices, these suggestions may make developing your Mosaic applications a bit easier.

Folder Structure

Organization will set you free – Alton Brown

Mosaic applications consist of quite a few moving parts.  There are the application descriptors, tile code, services and interfaces, authentication policies, shell skins, etc.  Keeping these sorted out will definitely make your life easier, especially when it comes to deploying and debugging.  Whenever possible, I prefer to keep all of the files/folders for a single Mosaic undertaking under a single folder.  That may mean having more than one application in the same folder, but at least the related code will be close by.

Under that parent folder I usually create one folder for each major Mosaic component.  The folder names are in lower case to differentiate them from the Catalog’s folders (more on that later).  For example:  I have a project called the Sales Dashboard, which will contain an application, catalog, several tiles, a service, a custom style sheet, etc.  To keep from going insane, I created the following folder structure:

topLevel

  • applications – this folder contains the application descriptor xml file(s)
  • catalogs – this folder contains the deployable contents for the project’s catalog.  If I was to have multiple catalogs, then they would each go in a separate subfolder.  A catalog’s structure is one of the few things that must have a specific structure.  This is because the catalog folder gets zipped and then deployed to the Mosaic server.  For more on the catalog folder’s structure, see the section below.
  • interfaces – this project uses a Mosaic Service component that is used by several tiles.  Each service component consists of two parts – the interface library and the service class.  This folder contains sub folders for each of the interface library projects.  Those subfolders contain a Flex Builder project that includes the source code for the interface.  In this example I have a single interface library called the “SalesDashboardInterfaceLibrary”, so the interface folder has a single subfolder with that name.  In the subfolder is a Flex Builder project for the interface:
    interfaces
  • policies – if you are using the Mosaic fine grained authorization, then this folder contains the XACML files that provide authorization information for the elements.
  • services – this folder is related to the interfaces folder.  It contains subfolders for each of the service class files.  Inside those subfolders is a Flex Builder project used to develop the service code.  For example, this application includes a “SalesDashboardService”. That subfolder contains a Flex Builder project for that service library:
    service
  • stylesheets – this project contains a custom skin for the Mosaic application.  The Flex Builder project for this skin is in a subfolder under the stylesheets folder.  If I had more than one skin, then each would get its own subfolder.  For example, my skin project is called “GlobalCorpSkins”:
    stylesheet
  • tiles – this folder contains sub folders for each of the Flex Builder tile projects.  Usually I try to keep related tiles in the same Flex Builder project (it makes debugging a bit easier), so a single sub folder may contain many tiles.  There are some cases, however, where a particular tile needs  its own project.  For example, if it uses a different Flex SDK or comes from a legacy application.  How fine grained you want to make the tile projects is really up to you, but keeping them all under this one tiles folder will make them easier to find.  In this example I have two tile projects – Flex 4 tiles (which contains several tiles) and Map (which contains a single, very complex tile):
    tiles

Catalog Structure

As I said earlier, the catalog structure is the one thing that must be in a specific format.  The catalog contains the deploy objects (compiled code, resources, etc.) and it will be zipped, then sent to the Mosaic server.  The server is expecting specific things to be in specific folders.  And yes, those folders are case sensitive.

catalog

  • descriptor.xml – this is the catalog’s definition file.  It must be named descriptor.xml and it must be at the root of the catalog zip file
  • Interfaces – contains the compiled swf for the interface libraries.
  • Resources – this is where the miscellaneous stuff needed for tiles and services is stored.  Things like images, XML files, videos, etc. are put here.
  • Services – contains the compiled swf for the service classes
  • Stylesheets – contains the skin classes complied into a swf
  • Tiles – contains subfolders for each of the tiles in the catalog.  The subfolder names is the same name as the tile, and they contain the tile swf files.

Flex Builder Linked Resources

Since tiles, services and skin projects rely on the Mosaic SDK, you’ll need to include the appropriate SDK swc in each of your projects.  Rather than hard coding the path, it is a good idea to create a pointer to the SDK folder and let Flash Builder sort out the location.  This makes your code more portable, if you give it to someone else, they don’t have to have the SDK in exactly the same location as you do.

To set up a linked resource to the Mosaic SDK:

  • Open Flex Builder
  • Choose Window –> Preferences
  • Choose General –> Workspace –> Linked Resources
  • Click the New button
  • Give it a name of MOSAIC_SDK
  • Click the Folder button and browse to your Mosaic SDK folder.  Don’t go any lower than the “sdk” folder.
  • Click OK to close the dialogs

When you create a new Mosaic project you can use the linked resource in your Flex Build Path.  Then if someone else opens your project and has the SDK in a different location, Flash Builder will sort out the reference (assuming they have a MOSAIC_SDK resource).

ANT Scripts

It may seem that I’ve gone a little berserk with the organization of the project.  I mean, how anal retentive can you get?  Why not just lump everything together in one or two folders and be done with it?

The answer lies in the application deployment through ANT scripts.  Having a highly organized structure like this allow you to build the deployment code as a few, small ANT files.  These can be combined together to quickly deploy code changes in an efficient manner.  There are few things more annoying than testing against the wrong code.

For example; At the root of the project I have an ANT script that deploys the catalog, application and policies.  Before that section executes, it calls ANT scripts in the sub folders that re-compile the interface, service, style sheet and tile classes, and move them to the appropriate location in the catalog structure.  Using this, I can make changes to a tile, run the root ANT script and ensure that everything is the current version.

True, it takes a bit more effort to set up, but the time and frustration savings are well worth it.  Here’s what my final folder structure looks like:

folderStructure

Request for Comments

For what its worth, most of the above is my opinion based on my own experiences.  If you have any additional suggestions, I’d love to hear them.