UI issue regarding current "Tense" & "Context"

General
1

I’ve seen this sort of ambiguous context in “professional” software and I’ve come up against this many times before in my own software solutions. This is NOT about coding but about UI. I think.

I have this - It’s a small panel of my program. To the user, it seems reasonable that to “Record”, then one simply selects the “Enable Record” button/checkbox. (That’s the only way recording can be done anyway).

After a couple of other steps, they are presented with this:

To me it seems obvious that in order to disable the recording (if required) the user de-selects “Enable Record”. The Software works as it should, but I don’t think the logic does - from the user point. Depending on the context, ie. if I’m being the “programmer or the user” then the Enable Recording button doesn’t make sense anymore. It should now say “Disable Recording” like a toggle switch. Earlier in this program I fiddled around with it but it never made sense, but I had to progress to other parts.

What complicates matters is that if you look at center of the panel you will see “Current Status”. This shows EXACTLY what the state is. This is the correct and current state of the situation. It works perfectly in that sense. Unfortunately the main button doesn’t reflect this.

The recording process is a complicated one. There are six steps required to actually record the data. I’ve tried to “dumb” this down via the “bouncing ball” method (an arrow in this case). I cannot take out any steps. When recording is enabled, then we follow the “arrow” as in image number two. This part has to be done. There are three options left to the user: “quit program”, “disable record” or “proceed”.

One option is to simply have a heading: RECORDING OPTIONS then a Segmented Control for ENABLE / DISABLE?. I have come to the point of my program that this issue has to be resolved NOW. Otherwise I will be faced with the “Penny Farthing Principle”. ie. Positive results only known by a select few who are willing to persevere.

One time, I did read in a book somewhere that “The essence of effective programming is to make an effortless transition between the programmer and the user”. Much easier said than done.

2

observations…

While I was reading through your post, I kept looking at the pictures you posted, thinking “where the heck is this checkbox he’s talking about???” It wasn’t until I got to the end and took a long hard look at it that i noticed that it’s in the blue tab itself, next to the title. That was completely unobvious to me.

Is there a reason you need separate buttons for Starting and Stopping a record? It seems that these functions are usually mutually exclusive and could be handled with a single button which changes state. It would save you tons of space.

Is there any reason that a user might re-record after one is completed? Maybe the answer is to prevent any new recordings from being created until the current one is finished?

3

If you have steps the user needs to follow then present the steps to the user in order. I missed the “enable recording” checkbox totally and had to look at the screenshots a couple of times.

4

Ok thanks Greg and Beatrix, further explanation is required.

Looks messy, but early stages.

The top right shows the results of a graph. The bottom shows the recording panel as previously posted, the other bits are mock-ups.

The hardware device, graph and software is almost good enough to show you the force if you farted on a popsicle stick. The question for me is should I include both in the same window? Well not farts and popsicle sticks, but to be able to record new data and show the data at the same time.

Sorry if I worded that poorly, it’s a hard one, and quite possibly a bad explaination.

Yep Greg, these functions are mutually exclusive. Different windows would work in a way that I want. It’s hard to include or allow for both scenarios.

5

Im sure there is more to it than I see above, but it sounds like you have a safety catch on a gun.

Enable the safety
Then say ‘I have a gun!’
Then click the trigger
Then the gun asks ’ you sure you want to shoot?’

Whats wrong with ‘Start Recording’ and ‘Stop Recording’?
They can even be the same button.

Maybe if the user clicks start recording, it does so in a new window without deleting the previous data?

6

I agree with Jeff. The enable recording button seems superfluous.

If a new recording overwrites the old recording I’d either give a warning or do a new window. How about switching controls and the recording? For instance Instruments from Xcode does both (new window and controls at the top).

7

Thanks Jeff and Beatrix, yes I do have the “safety gun”. I reckon It should NOT have a “toggle” button. It does not not make sense and I don’t like it. I’ve tried this before. Now I’m thinking it does need to be more explicit. The “Current Status” is indeed explicit anyway,

What you are seeing in the above image is non “volatile” data. It shows you the results of the previous calculated recorded data. Therefore the “Recording Option” is disabled. If you want to record NEW data, then you will be given an option via a dialog box if you want to overwrite the existing data Yes, that does HAVE to happen.

It has to happen. What I’m trying to achieve is that both can be represented in the SAME window.

Regargleness , that is my objective for this post. Nothing to do with coding, but how you work out the “user”.

So that the user has least surprise.

8

Since you’re showing a warning dialog, there is no need to disable the record button. That needlessly complicates things. It sounds like there’s only one previous recording, so it’s not like the user is going to bring up your app to review historical data. The whole point is to record (as far as you have described the functionality) and then review the current data.

9

Thanks all. There are a few things that need explanation (my fault).

Starting with the purpose of the Software:

The Software should be able to record data, save data, edit and analyse data, open saved data and import data from different recording devices in plain numerical text and/or a *csv file, then show results. The specs and performance area are just basic calculations and not relevant at this point.

Let’s concentrate on the “recording” process. I “assumed” it would be easy and obvious to see the “ENABLE Recording” button. Seems not so. There is always a “Learning Curve” with all software. If you understood what you had to do, then it would be easier. What I’m getting at is that this Software is aimed at a particular profession that would understand. “Joe Blow” off the street would have no idea, and also no requirement.

Nevertheless, it seems the button in question is not obvious. My question was regarding “context” NOT if it was obvious that a button could be pressed. This has always been an issue in many programs I’ve written. Meaning when the user presses a “toggle” type button, the meaning and context should be relevant.

This is what I’ve ended up doing - I think it makes sense this way.

It’s also very important to point out that once the recording process is initiated, the user could in theory, have many (seven+) steps to go through before being able/allowed to record (important - if anyone is interested I’ll explain further). Regardless, after selecting enable record, the user is ALWAYS left with only three options*:

  1. Proceed to the next step (as it should be)
  2. Disable the recording (ie. mistake or just checking/evaluating)
  3. Exit the program
  4. Ummm…or CTRL+ALT+DEL ?

I wanted to make the recording window look “disabled” ie. everything looks grey. But now, after learning that it is not so obvious, I have made the “ENABLE Recording” button a darker grey"

When the user selects “ENABLE Recording” the box is highlighted (blue) and the caption changes to “Recording ENABLED”. You can backout by unchecking the checkbox back to the above state. But we progress . . .

Going through the steps, then finally the “Record” button becomes highlighted. (we can still back out)

Once the Record button is pressed *then you will see that the checkbox selection becomes disabled. There are only two options left. Stop the recording (ideal) or Quit (data lost)

I think this makes sense. To disable the recording, we simply “uncheck” the Recording ENABLED" button. (All becomes grey/disabled again). At one stage I had the caption change to “Recording DISABLED” and then had to decide on the state of the checkbox? utter madness.

I think I now have a reasonable solution. I don’t think any software is perfect. If we try to maintain the same “context” throughout then we have reached our goal to ensure that the “user” is not baffled. You will also see a status area in the middle of the panel - this is always correct. It’s been hard to ensure that the status area does not conflict or contradict the the enable recording button.

Happy to hear alternative ideas.

[EDIT] And yes, Implementing the recording with previous data in the graph window MUST show a warning. Although not a great fear of data loss, because the recorded data will always have a backup providing stop record is selected - which is what the user is forced to do anyway :slight_smile:

10

Can the user select multiple device sources for the record action? If not, then simply show the state of the source that the user selected (in Preferences / Settings).

On every other app that records data - audio, video, raw - that I’ve ever seen, the record button is a single button with double duty - if not recording, start, and if recording, stop. No need for a separate button.

Your status block is superfluous since the recording button already provides a very visible state of “Recording” or “Not Recording”.

Taring should be automatic unless the recording is appending data to previously recorded data.

What is “Done” for? It looks like its function is just as a state indicator. If if doesn’t do something when the user clicks it, it shouldn’t look like a button.

Summary - All of the device status is “Information”, the second column and the "Current status should go away, the “Record” button should be a single, toggle state button and yhje “Record” / “Stop Record” “buttons” should be removed.

This would get that section of your screen down to a single row of around 32 pixels high.

11

From what you’ve described, it really sounds like the recording process should be a separate window. That would make both the initiation of the process, as well as the termination, much more intuitive. Ie., you want to abort midway? Close the window.

12

Thanks Tim(s).

@ Tim Hare: Yes, that was an option I looked at and thought very carefully about. The other way is, when the program starts, you are presented with 2 options: Record or Review/Analise Data. In the end I made the decision to keep it all in the one window.
The idea being that the User doesn’t need to look anywhere else.

@ Tim Jones: Thanks for all the ideas. The Record/Stop Record scenario is neither here nor there, I’ve seen both. The DONE button means CONFIRMED, so I could change that. Every single step IS required. I believe there is nothing there that doesn’t need to be. It took me some weeks of adding/deleting etc. and I couldn’t trim any further.

The status area is very important. Apart from the text info, it also shows you the “live force” that is applied by an external load cell device. This is needed for “CHECKING”. You may also notice the ‘hardware’ checkbox. When selected this shows you the actual raw data being read from the device - essential for ‘physical’ re-calibrating of the load cell amplifier. That’s the reason why the TARE button is there. In actual fact, when the software connects to the device is does automatically tare, but can be re-tared if nesser.

I could have the hardware checkbox on some sort of options page, but would prefer it all to be there easily accessed.

The load cell (Impulse Recorder) will be used in the field, ie. outdoors at a safe location. It’s typical use is for recording the performance of rocket motors. (approx. 30kgs max force with my model). When users are experimenting with their various designs, there is often a catastrophic failure (CATO). After such an event, it’s good to be able to check the hardware.

The reason why the control buttons are big is so it can be easily seen outdoors. The recording panel is driven by the ‘spacebar’.

So, the checking process is a ‘physical’ confirmation the system is working correctly via testing with an actual known weight. After confirmation, we are ready - all systems in place and the area is safe, we start the recording then initiate the ignition. All going well stop the recording. Analysis in the field is important because in may determine what or not to test next.

13

I forgot to reply to this bit:

Tim Jones:

Yes, Tim. The user will be able to select a different device or source. (yet to be implemented). That is, either from another hardware device or importing data that was recorded on a different device. The sample rate (Hz) and resolution (grams) has to be known otherwise the math will not calculate correctly.

So, I do have to face the reality that I will need another window for Preferences/Settings. And of course file importing/saving etc. Therefore why not have another window for recording? What concerns me is if I don’t take a certain approach now, how hard will it be to unwind?

So, Tim Hare’s solution with the separate window is likely the right way to go. For me, that means a new approach and more (harder) programming. The more I think about it, perhaps it’s the best way. At this point, having the recording options in the same window means that I have to disable the selection of other controls, although I could put them all into a group box or panel? Ultimately an exercise in futility . . . maybe.

Anyway, I’m a part-time “hobby programmer” So just going through this process has helped a lot. I don’t really have many other options to bounce ideas off. This Software is not for major release but I want to get it working correctly. There is a small niche market in amateur pyrotechnics and a competitor is selling a substandard device and software. It would be good to sell at least one working product.

This is the hardware device. At least I know this part is working.

14

I think you are significantly overestimating the difficulty of using multiple windows. I suspect it will actually simplify things for you.

15

You’re probably right there Tim.

From my point of view it’s been an achievement to get to this point and now “I’m going to break it” :slight_smile:

Cheers.