« first day (316 days earlier)      last day (4367 days later) » 

Erics
Erics
1:23 AM
@BenBrocka makes sense. note though that there is still no interaction inside the dialog .. there is possibility of lost effort.
 
Erics
Erics
1:58 AM
^ "no possibility"
ouch, that's one dang urgly UI...
2
Q: Best approach for capturing data for items in a listbox

RichI have a series of cascading ListBoxes in an aspx page. This UI was selected to allow the equipment list to be filtered by Assigned Services and then Equipment, which in-turn will allow the user to select multiple Assets with Shift+Click. Each Assigned Asset can be assigned a Start or End Dat...

gui-design user-interaction
good question though (modulo the "best" cancer)
 
Rahul
Rahul
@Erics Challenge accepted
0
A: Best approach for capturing data for items in a listbox

RahulFirst I'll answer your question on the surface and then I'll drill down and look at the bigger picture. Capturing dates Listboxes are unique controls in that they allow you to select one or multiple items, but the option to select multiple is arcane and unfamiliar to most users. This makes usin...

 
Erics
Erics
2:21 AM
I too was thinking a table. the task is not dissimilar to a shopping basket (or travel itinerary)
 
Rahul
Rahul
Yeah, I was going to suggest facets, but I think that's a bit over the top
The OP is asking for a surface solution, so detailing a completely different UI is probably not going to help him
When in doubt, do what Hipmunk does
 
Erics
Erics
still would be useful to have the two filters .. they may not have any "Nikon" assets available and if you don't know what other cameras are available then an asset search field is useless to you
the MVP would be to incorporate the date range into the asset text in the last listbox (or "(specify dates...)" text), and only show the date fields if the user clicks on a selected asset.
probably still need to be able to select multiple selected assets, to assign the same date range to the whole check out in one go. Sure wouldn't want to type the same damn date range in for each gorram asset, one at a fracking time.
he should prototype the alternatives and do some quick tests ... which reminds me: your view on paper prototypes and corridor testing?
might have to fire up the laptop so I can answer it too .. dread doing that from the iPad.
 
Rahul
Rahul
3:16 AM
@Erics Define "paper prototype" - I've always found it a clumsy term
You can't do anything interactive on paper, so really it's best to just call it a "sketch"
 
 
1 hour later…
Erics
Erics
4:43 AM
@Rahul lots more to it than a single sketch - fully interactive, using bits of paper for drop down menus etc
“Paper prototyping is a variation of usability testing where representative users perform realistic tasks by interacting with a paper version of the interface that is manipulated by a person ‘playing computer,’ who doesn’t explain how the interface is intended to work.” Quote from Carolyn Snyder.
 
 
12 hours later…
Rahul
Rahul
4:58 PM
That's not fully interactive - that's switching out bits of paper to suggest state changes
Interactivity is more than changing state
 
 
4 hours later…
Ben Brocka
Ben Brocka
8:43 PM
@Erics yeah that's a big part of it. But if effort could be lost it could be kept in the form (for a log in modal) or the user could be prompted to save/cancel if it were a significant form
 
 
3 hours later…
Erics
Erics
11:39 PM
@Rahul perception is everything
The Turk
The Turk, also known as the Mechanical Turk or Automaton Chess Player (, "chess Turk"' ), was a fake chess-playing machine constructed in the late 18th century. From 1770 until its destruction by fire in 1854, it was exhibited by various owners as an automaton, though it was exposed in the early 1820s as an elaborate hoax. Constructed and unveiled in 1770 by Wolfgang von Kempelen (1734–1804) to impress the Empress Maria Theresa, the mechanism appeared to be able to play a strong game of chess against a human opponent, as well as perform the knight's tour, a puzzle that requires the play...
 
Rahul
Rahul
@Erics Anyway, I think paper prototyping is great early on in the process, but real prototyping can't happen until you're building with the same materials as the final product
 
Erics
Erics
so no prototyping in html if you're planning a native app?
really though, what you prototype in depends on what you intend to do with the prototype, what you are aiming to learn. A prototype is not a deliverable.
 
Rahul
Rahul
Ideally, no, but I guess it depends on what you're making. If the app is just a simple set of views moving back and forth, there are HTML frameworks that closely reproduce that behaviour... but if you're making a custom iOS app that benefits from hardware features or deviates strongly from the HIG, then you should prototype natively
Yeah, exactly
Not everyone realises or thinks about that, though
Another thing a lot of people think is that the prototyping process should be "fast" or take very little time
Which makes no sense - prototyping is supposed to help you root out problems with "manufacturing" (eg. production) so you should spend as much time as you need to feel comfortable
In that sense HTML prototyping or something with a similar granular fidelity is much better than, say, claiming an Axure mockup is a prototype and using that to fuel assumptions about behaviour and usage
You should sweat the details of the prototype as much as you would sweat them in production
The details matter
@RogerAttrill "Even bad interfaces are designed by their creators. They may not mean to be designed to be bad, but neither are they designed to be good - they are just designed to meet targets and ship products. " great quote
 

« first day (316 days earlier)      last day (4367 days later) »