Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 4 years ago.
Improve this question
I've been searching a long time for some guidance or examples of web form design of large forms (dozens of fields - maybe 50+) for a user base that will be trained on the application.
99.9% of the guidance seems to be geared toward "accessibility" or "intuitiveness" which are, by all means, valid goals. The issue is that a form that will be used on a one-off or infrequent basis by users who will likely be encountering it for the first (or only) time has much different considerations required compared with a form for data entry to a business application that will be used repeatedly all day long by users who are trained on the app.
If I'm designing for a one-off (say a sign-up form) then I want to focus on designing the form so that the user can't help but flow naturally through the steps and end up completing their goal and feeling all warm and fuzzy.
If I'm designing for an experienced user that will use the form 20x a day, they are going to want it designed to minimize the clicks and navigations, etc. They don't care [as much] about looks or flair and subtle cues to help them work through the form. They know the form like the back of their hand and just want to be able to enter data as quickly as possible and see as much as possible in one view.
The requirements that I'm getting from the users is that they want to see "everything" on one screen. They don't want to have to scroll. They want to minimize clicking to other pages to continue working.
Does anyone have any suggestions/links/dire-warnings??
Thanks,
Dave
My instinct is to tell you to break it up into sections the user can navigate between, to minimize the amount of continous data entry they have to do, as well as keeping the sections you have to validate to a minium. Get all the way to the bottom only to have to scroll back up to the top... annoying!
Since you want a large form, however, my suggestions are:
Validate as you go. As soon as a user leaves an input or section let them know everything is okay. Don't glue them to a control though, use visual feedback (like backgrounds going red or similar).
Don't lose that page! Use whatever technique you can (including background submits) to store the user's states. Funnily enough, a certain user driven programmers community website does that...
Tab navigation! Set the tab order! Your keyboard wizards will love you
Although you might want to jam as much as possible onto one line, don't. Keep good spacing and vertical navigation - people are used to scrolling vertically, and good spacing makes things readable.
There's lots more, but, as you might expect, there's an even better answer, here
We touch on the key drivers for designing forms for high-usage, trained users in our book "Forms that work".
The key points are:
Try to cram everything onto one page, as described. Having to click from screen to screen becomes very tiring very quickly when you're using the same form all day every day.
If you must separate off some items, do extremely careful observational analysis to discover which items are genuinely used rarely. Put those ones on the 'extra click' screen.
Abbreviate the labels ruthlessly, taking advice from the users on what abbreviations are required. They'll rapidly stop reading the labels anyway, working mostly from the absolute position of fields relative to each other...
... which means: don't ever allow fields to move about. Make sure they retain their absolute position; this is essential for speed of completion
Make sure that the form is entirely navigable using keystrokes alone. This is essential for speedy completion by experienced users
Find out where the answers come from to go into the fields. If they are typing in stuff from another document (it does still happen, believe me) make sure that the field are arranged in the same absolute positions to each other as is shown on the layout of the document they are typing in from.
Don't worry too much 'intuitiveness'; these people are going to be trained.
Bounce rate is completely irrelevant, so you can skip any advice you see about 'conversion' or 'bounce rate'. These users don't have the option to go elsewhere and do a different form.
Email me directly if you'd like to discuss this in more detail: Caroline Jarrett. More contact details on Forms that work - our book's web site
I've got two suggestions. Keyboard and consistency. The one thing you want want when using a form like that so often is the ability to do it with your eyes closed.
The focus should be at the first field, from there on it should take the exact sequence if keystrokes to fill and submit the form every time. Normally this means and type till all fields are filled after which you can press enter to submit.
And try to get audio feedback in there when something goes wrong, often people type blind and have their eyes on a piece of paper and not on the screen, a simple beep to tell them to look at the screen really helps.
hmmm,
I understand that the client wants it done on "one" page however if this will rarely be used like you say I would give it to them in bite sized pieces or your bounce rate will go through the roof.
here are some links using jquery to forms similiar to what I am refering to:
http://www.thecodemine.org/
http://cardonadesigns.com/wordpress/thoughts/ajaxish.php
http://jquery.bassistance.de/validate/demo/multipart/
to name a few.
Related
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
We are starting to use Kanban and my boss just asked me a question, as one of two people with prior Kanban experience within the group, that I don't really know how to answer.
My previous experience and training with Kanban had developers pulling stories in from the backlog by priority, in our case that was the topmost card. However, my boss would like certain stories to go to the developers that have domain knowledge for particular areas. For example, let's say Joe has the most experience in working with Contracts and a contract story comes onto the board. He would like Joe to be the one to work on that particular story.
This, to me, feels a little "off" and could lead to some developers having significant extra work due to having worked in any given area of functionality. My previous experience with Kanban worked under the assumption that any developer should be able to pick up the next card and figure out what to do and that this practice would eventually eliminate any single functionality area experts and level out developer expertise over time. However, I can also see how using subject matter experts can help move a story through the process faster.
What is the most "Kanban" way of handling priority vs. expertise when it comes to pulling in the next story?
Every system I've ever worked with allows a little bit of developer-level of prioritization. If the next card has the absolute (top-down driven) priority, then you have to pick that card. Mostly, though, I tend to work in places where "these next 6 cards are up, pick the one you like". This gives the developer a little bit of room for type of work he or she prefers. Plus, it gives the developers a greater sense of ownership since they did get to pick (to some extent) the work they were doing.
Regarding your example, it's a little off base. In an ideal world any developer should be able to pick up any card. In reality, this isn't always true. If I give this project to Jim, it might take 2 days. If I give it to not-Jim, it make take all week. This is a sign! What information sharing is missing? How do you get the other developers to understand the Contracts component as well as Jim?
If the priority is a little bit gray, this stuff tends to work itself out. All the other developers know that Jim can handle the Contracts stuff. However, if Jim has no capacity, then someone else must take up the challenge. Kanban is supposed to alert you to blocked stories.
Kanban is great for visualizing work flow, limiting WIP, and exposing bottle necks.
Henrik Kniberg has a great book, 'Lean from the Trenches'. He talks through many techniques he has used in real world examples. He described one approach to having avatars (that represent developers) that can be placed over task to show who is working on what.
One idea for your situation, would be to use this avatar approach to pre-assigning who should work on a task in the buffer leading into development.
If those pre-assigned tasks are not causing bottlenecks and flow is natural, everything is good. If they are causing bottlenecks early in your flow, you have a problem, but now you have an easy way to visualize and see that it is the pre-assigning that is causing your bottle neck!
A Kanban system shall display the real process. If the manager is assigning stories to developer then the system should reflect that. This can be done in several ways, you could have a specific item for developer X or you can write the developers name on the card. Another option is to have one swim-lane for each developer.
However, all of this is probably not good from a "global" perspective. You should share your Kanban data with your boss. What are your lead-times, what is your throughput etc? Then you should invite the boss to the process improvment meeting. How are we going to improve our figures? Hopefully he sees that Joe probably will be a bottleneck if he is assigning tasks directly to him. Teach him Littles Law, teach him about bottlenecks and Lean in general.
Don't forget to make your policies explicit, that is, it should be written on the wall how your prioritzation policy looks like. Good luck!
So I've been having a cordial debate with my coworkers (developers and designers) about the autofill tools for web forms. This is an important development question as it affects how forms might be built.
Q) What is the adoption of autofill tools, such as Google Toolbar or Chrome's built in feature?
Q) What are the most popular autofill tools?
Discussion appreciated. First answer with a reputable study gets the award.
Personally, I do not like auto-fill tools, and toolbars for that matter. Aside from the loss of screen real estate, there's too much bloat that comes with them. Also, with the way browsers versions are increasing, auto form fill applications are sometimes not supported in newer, more modern browsers.
I've worked in Government, Law enforcement, health care, and other public and private institutions and I have yet to see a good working form autofill tool, and if I did find a good one I can grantee that someone will be calling tech support because they submitted X amount of items with the exact same data.
HTML Forms can be built many ways, and forcing someone to build it a specific way is going to limit people, thus a form should be able to be built however someone wants, hopefully following W3C standards.
That being said, the most intuitive ones are those built into an application - where the developers/BA's create the auto-fill rules based on business cases and the correct algorithms, where users can define specific fields and parameters for data in those fields. Forcing an application to be built to match a 3rd party auto fill tool, which could change at any moment, or not be supported in the future, seems risky, I hear bells.
Update:
As far as revenue concerns, or a revenue stream for such a venture, you have to have an insight on the types of users that would use this software.
A form filler needs to be more than a generic: "This is a login page, let's put a username / password in". or a contact page "This is the previous data you used for a contact me page, fill it in".
A previous system I developed was an Action Item tracking system, with build in workflow / document management. Users asked for an auto fill for these items, which on the first request seemed utterly insane (demented is the word I wanted to say, but my manager helped me keep it bottled up). How would an auto-fill utility know exactly what to fill - but as I talked to the customer they expressed the following, which is valid for all autofill tools:
When I enter in a value say "Jane Smith" for "assign this task to", it would be nice if your system would automatically put "In Progress" for the item, as I always select "In Progress" as the status for this user.
As well, this worked for other users and fields as well. There was a specific flow on how this user entered data. "Jane Smith" items were always set to a specific department, status, and if the Item Type was say "correspondence" the Estimated Time was always 8 hours.
That type of auto-fill is what we custom made for them, and they payed well for it because it saved them a lot of time, mouse movements etc. AutoFill the way it is now is annoying at best for some people. But it's the pattern of the data that matters. It has to be intuitive and learn.
Once we developed this (it was easier because it was our application, we knew what was going on), about 90% of our customers jumped on board in the first week because of the time savings, sanity savings, and they didn't need to do ANYTHING to set it up - which was key.
I'm new to iOS Development and am trying to make an application that essentially sorts through a list of 300 names or so. I've got the Drill-Down part of the application down, aside from the detailView, but am now faced with a challenge.
What I would like to do is have users select from 3 fields with a UIPickerView to come up with shorter lists for every time a user is looking for a person. I'd like to use a .plist, but I also have an XML feed of the information. Before I waste all of my time structuring these data sources, does anybody have a good overview as to how I should approach this?
Also, I've asked some this question before, and they tell me to read up on introductory iOS development topics. I understand the mechanics of development, I just can't ever figure out how to approach a task properly. (I'm working on it!)
Thanks in advance. I'd share an image to help clarify, but my rep isn't high enough.
Snip: It looks like I misread your intention which makes my earlier comments irrelevant, you want to have the user select one of 3 options to shrink the list, if I'm not mistaken.
Some more questions for you, so I take it that this XML feed is going to be potentially changing between times that the user loads up the app? Will it only ever grow or are those 300 or so names that are loaded once set for good? The reason I ask so that you can maybe see my train of thought is whether or not using Core Data might be useful. You could easily store your large list locally, save time having to reload this large list frequently, and also you can use the built fetchedObjectController to search your collection of names. I'll keep thinking about it and once you get a chance to answer these questions we can continue.
Ill check back for an edit or comment, and see if I can give you an approach. Also, maybe edit your question with any of your own approach ideas and we could also start from there and refine them if needed.
Edit 2: From the information in the comments this is one of the ways that I could see this being done that make sense to me:
Since you seem to be able to control the information you receive from the feed I would set it up to send you only the contacts that need to be added/removed. You could handle this a few ways depending on your deployment intentions but I would go with the following:
Find a way to signal a first time run of the application, and as a result all contacts would be new, and you could populate your list fully with a slightly longer first time setup. Then any further changes could be quickly handled by smaller edits made to the local list.
You would need to set up Core Data for your application, which should be fairly straightforward in your case, and after this you can use the built in NSFetchRequest to do your searches that will then quickly return a list of narrowed down contacts. As for the physical picker that is just a matter of building the UI which will require some design from your end as you are the only one that knows what you are going for in that regard. Depending on the complexity of your app and what functionality you will want to include you could get away with 1-2 views that simply do the displaying of the contacts in a table and then the picker just reloads when appropriate.
I'm not familiar with the implementation of XML Feeds and receiving data from them, but I have done XML Response parsing into Core Data from a SOAP service before and they shouldn't be terribly different.
Regarding resource to get you started should you need them, I would recommend the following:
eBooks:
http://www.techotopia.com/index.php/Objective-C_2.0_Essentials
http://www.techotopia.com/index.php/IPhone_iOS_4_Development_Essentials_Xcode_4_Edition
Tutorials:
http://www.raywenderlich.com/
The eBooks I have linked are both absolutely fantastic and one of the few xCode 4.0 books that I was able to find that seemed to be of an actual usable quality. They both contain easy to follow and clear tutorials on simple and more advanced aspects of programming for iOS.
Ray's site is an immensely helpful resource as it contains both a very active forum base for iOS programming in addition to a constantly growing tutorial collection as there are 4-5 people that constantly are creating new tutorials that the community votes on and suggests every week. It contains some more advanced topics than the above books and I would recommend looking at it after doing a few walk through/tutorials from the books.
I'll stick around if you have any further questions, otherwise you can send me a notification via these comments, or just post another question and someone is bound to help you out!
-Karoly
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
I've just picked up a contract to sort out a vipers-nest of e-commerce websites that a previous 'developer' left for one of my clients. There's about a couple of dozen of them using a custom shopping cart and CMS system that's too embedded to dump and works well enough, but desperately needs cleaning up, re-factoring, and bug fixing, so a reasonably substantial recoding job.
As part of this my client is desperate to ensure the best search engine placement he can get. Like many developers I've a nodding acquaintance with the idea, but no real knowledge, and it seems that it would be helpful to get up to speed on this so I can build appropriately into the code.
So can people advise on useful quality resources - books, websites, blogs etc? I do not wish to obsess over every last detail on this (he can use a specialist if he decides to pull every last ounce out - although I've always regarded such as little better than snake-oil peddlers), but I would like to build code and reconfigure templates in a manner that helps rather than hinders placement.
Look at Wikipedia with styles off. See how they order their content? See how they use correct tags to label the content? These are the keys to long term success.
The most important SEO advice is to create a semantic, logical site. The content comes first and is ordered by importance. Use the correct tags, don't do tables. Then apply styles. Then apply script to make it fancy. (Like Tomas said)
Know the difference between what is content (pictures of your products) and not (your logo tiled on the background). Basically do your best to present good content in a good way. You can't game the system for long term gains.
This will give you long term placement. Most SEO companies just do tricks or links farms or worry about keywords and meta tags, so they are temporary at best. I think it is good to assume that Google works just as hard to drop that crap from it's index as the SEO marketers do to include it.
According to Google's patent
Age of domain.
Important sites that link to you.
Content. Make it real and accurate.
http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=/netahtml/PTO/search-bool.html&r=1&f=G&l=50&co1=AND&d=PG01&s1=20050071741&OS=20050071741&RS=20050071741
A main concern when thinking SEO should always be usability. Make sure the mark-up is semantic, make sure the site works without javascript, css and images - in other words, make sure that 'low-level browsers' are able to read the contents of your page. Think of optimizing the site for a screen reader for the blind and visually impaired, and you will automatically cover the search engines, because that is exactly what they are - blind browsers.
A standard no-no is a table layout, mainly because it does not order the site content by relevance. To a human being reading your site, it is no problem looking two inches down instead of at the very top of your page, but the screenreader reads the code, not the visual view.
Thus, you should make sure that you have the important things - a high-level heading (preferrably <h1> or <h2>), the main menu (in a <ul> list) and the content in divs at the top of the source, and less important content (the logo, banners, quickmenus etc that aren't really crucially needed to be accessible) further down. You are always able to re-order where the stuff is actually shown in your css.
New tag to use called CANONICAL can now also be used, from Google, click HERE
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I'm working in a small company and weeks away from deploying a web-app that will be used a lot. Everyone at one location will have to learn to use it, and although I think it's pretty easy and intuitive I may be biased.
I've written a help guide with plenty of screenshots that's available on every page, but I'll still need to train everyone. What's the best way? How do you take a step back and explain code you've been working on for weeks?
First try to avoid the training:
Perform usability testing to ensure your web app is intuitive. Usability testing is a very important aspect of testing and it is often ignored. How you see your system will probably be very different as how a new user sees your system.
Also add contextual help as often as you can. For example when I hover over a tag in stack overflow, I know exactly what clicking it will do, because it tells me.
Also this may seem obvious, but make sure you link to your documentation from the site itself. People may not think of looking in your documentation unless its right in front of their eyes.
About training documentation:
Try to split up your material into how your users would use the system. I personally like the "trails" option that Sun created for their Java tutorials. In this tutorial you can do several things, and you can chose on which trail you'd like to go.
Support random reads in your help documentation. If they have a task to do in your web app, then they should be able to get help on that without reading a bunch of unrelated content.
Make sure your documentation is searchable.
About actual training sessions:
If you are actually performing training sessions, stay away from explaining anything related to your code at all. You don't need to know about the engine to drive a car.
Try to split up your training sessions into very focused aspects of your system. If you only have 1 training session available to you then just do one specialized use case of your system + the overall description of the system. Refer to the different parts of documentation where they can get help.
Letting the community help itself:
No matter how extensive your documentation is, you'll always have cases that you didn't cover. That's why it's a good idea to have a forum available to all users of the system. Allow them to ask each other questions.
You can review this forum and add content to your documentation as needed.
You could also open up a wiki for the documentation itself, but this is probably not desirable if your user base isn't very large.
Few ideas:
Do you have some canned walk-through scenarios? Don't know if it is applicable for your product, but I built a pretty substantial product a couple years ago and developed some training modules that they'd work through - nothing long, maybe 15 minutes tops for each one.
I put together a slide presentation that hit the highlights to talk about what it does. I would spend about 10 minutes going through the app's highlights to familiarize them with it before doing the hands-on stuff.
People don't tend to read stuff, unfortunately. You could put hours and hours into a help document, and still find that folks simply don't read it or skim over it. That can be frustrating. Expect that answers that are in your guide will be the topic of questions your users will have.
Break up any training you do into manageable chunks. I've been to a full-day training exercise before and the trainer broke it into short pieces and made it easy for me to get the training topic in my head. You don't want to data-dump on them because their eyes will gloss over and you'll lose them.
Ultimately, if your app is highly usable, it should be a piece of cake. If it isn't, you'll find out. You might want to have a few folks you know run through your training ahead of time and give you constructive criticism on it. Better to fix it before the big group is trained. You'll be more confident in the product and the training materials (whatever they are) and you'll likely have a better training experience.
If applicable, provide an online help/wiki/faq for them. Sometimes that is helpful.
Best of luck!
You should really have addressed this issue a lot earlier in the development cycle than you are doing.
In my view the ideal scenario for corporate software is one where the users design their own application and write their own documentation and I always try to strive for this. You should have identified key users early on and designed the system with them (I try to get my users to do basic screen designs and menu layouts in Excel or similar - then I implement that as static pages and review before writing a line of significant code, obviously they won't get the design right first time, but it's your job to guide them - and ideally in a way where they think they came up with the correct design decisions, not you :-) ).
These users should then write the user documentation from this design in parallel with you developing the system. I have never seen help documentation delivered by a IT department/software company used significantly in a corporate setting. Instead what happens is the users will create their own folder of notes and work-arounds and refer to this (in fact if you're ever doing system analysis to replace an existing system finding the 'user-bible' for the old system is a key strategy). Getting the users to write their own documentation up-front simply harnesses what will happen anyway - but this is vastly easier if the users feel they have ownership of the system because they designed it themselves in the first place.
Of course this approach needs commitment and time from your users, but generally it's not that hard a sell. It's trite, but working as a facilitator so the users can develop there own system rather than as a third party to give them a system pretty much guarantees user acceptance.
As you are where you are you're too late to implement all of this, but if you can identify a couple of keen, key, users and get time from them to write their own documentation then that would be a good move. If you can't get even that then you need to identify an evangelist who you can train to be the 'departmental' expert and give them 110% of your energy to support them.
The bottom line is that user acceptance is based on perception, and this does not necessarily correlate with how usable an system actually is. You have to focus on the group psychology of this as much as the reality of the system, which tends to be tricky for developers as we're much more factually based than most people.
I'll be looking into something like this too in the next few months.
In your case, hopefully the UI has already undergone user acceptance testing. You say you work in a small company. Is it possible to get the least tech-savvy person there to try it out? In fact, get them to try it out without any guidance from yourself except for questions they ask. Document the questions and make sure your user-guide answers them.
The main thing for me would be logic and consistency. If the app's workflow relates logically to the task it has been designed to accomplish and the UI is consistent you should be OK.
Create a wiki page to describe the use of your system. Giving edit rights to the users of your system lets the users:
update the documentation to correct any errors in the initial release of documentation,
share any tips on usage they may have found.
share unusual uses for the system that you may not have thought of.
request features.
provide any workarounds they've found while waiting for the new functionality to be implemented.
Try a few users first, one or two in a small company. Mostly watch, help as little as possible. This tells you what needs to be fixed, and it creates an experienced user base - so you are not the "training bottleneck" anymore.
Turn core requirements/use cases/storycards into HowTo / walkthroughs for your documentation.
For a public training, prepare a 10..15 minute presentation (just that, not more!) that covers key concepts that the users absolutely must understand, than show your core walkthroughs. Reserve extra time for questions about how to solve various tasks.
Think as a user, not as a techie: - noone cares if it's a SQL database and you spent a lot of time to get the locking mechanisms right. They do care about "does it slow me down" and "does something bad happen when two people do that at the same time". Our job is to make complicated things look easy.
It may help to put the documentation on the intranet in an editable form - page "comments", or wiki maybe. And/or put up a "error wiki" for error messages and blips - where you or your users can quickly add recomendations, workarounds and reasons for anything that does not go as expected.
Rather then train all those people I have chosen a few superusers (at least one person from each department) and trained them to teach the rest of the employees. It is of course vital that those super users are
well respected in their departments
able to teach
like the application
The easy way to ensure that they like the app is to have them to define the way it should work :-). Since they should work with this app each and every day they are the prime stakeholders, no matter what management states