I need opinions - usability - not sure where to ask this
-
So I have an app that's designed to run on a piece of hardware intended for musicians, who are not tech savvy. They also use equipment that can produce corrupt files, although that's not exceedingly common. My software boots and reads an inserted SD card. Currently during this process it loads each MIDI file and scans through its entire contents to determine if its valid before adding it to the list of available files. That way, corrupted files do not appear in the list. It also means I can display more information about each file. Once loaded, you scroll through the file list with a small rotary encoder (a knob basically for those of you that don't know what one is) The issue is this: The title screen can take some time to load. It's not terrible with a dozen files, but more than that and it starts to be like "hurry up!" Couple this with the difficulty of scrolling through a ton of files with just a knob. I'm thinking this is okay. Basically, don't put 100 files on an SD card. What do you think?
To err is human. Fortune favors the monsters.
-
So I have an app that's designed to run on a piece of hardware intended for musicians, who are not tech savvy. They also use equipment that can produce corrupt files, although that's not exceedingly common. My software boots and reads an inserted SD card. Currently during this process it loads each MIDI file and scans through its entire contents to determine if its valid before adding it to the list of available files. That way, corrupted files do not appear in the list. It also means I can display more information about each file. Once loaded, you scroll through the file list with a small rotary encoder (a knob basically for those of you that don't know what one is) The issue is this: The title screen can take some time to load. It's not terrible with a dozen files, but more than that and it starts to be like "hurry up!" Couple this with the difficulty of scrolling through a ton of files with just a knob. I'm thinking this is okay. Basically, don't put 100 files on an SD card. What do you think?
To err is human. Fortune favors the monsters.
Do not wait for the scan to finish all the files. When one scanned add it to the list and to the screen (scroll in the new ones) It probably will take more time to finish the scan but the end user will not wait on empty screen As for the knob - IMHO it is much better than push buttons...
“Real stupidity beats artificial intelligence every time.” ― Terry Pratchett, Hogfather
-
Do not wait for the scan to finish all the files. When one scanned add it to the list and to the screen (scroll in the new ones) It probably will take more time to finish the scan but the end user will not wait on empty screen As for the knob - IMHO it is much better than push buttons...
“Real stupidity beats artificial intelligence every time.” ― Terry Pratchett, Hogfather
That's an interesting idea. I'll consider it. My main concern with it is if the list isn't done loading it will be hard to tell when it's done and you've reached the end or if there's more to go. I guess I can squeeze an indicator on there but the screen is very small. Also it displays only one file at a time due to the size of the screen, and displaying information about each file, so there's no "list" to scroll. Plus scrolling is out of the question for performance reasons the way these little gadgets work.
To err is human. Fortune favors the monsters.
-
So I have an app that's designed to run on a piece of hardware intended for musicians, who are not tech savvy. They also use equipment that can produce corrupt files, although that's not exceedingly common. My software boots and reads an inserted SD card. Currently during this process it loads each MIDI file and scans through its entire contents to determine if its valid before adding it to the list of available files. That way, corrupted files do not appear in the list. It also means I can display more information about each file. Once loaded, you scroll through the file list with a small rotary encoder (a knob basically for those of you that don't know what one is) The issue is this: The title screen can take some time to load. It's not terrible with a dozen files, but more than that and it starts to be like "hurry up!" Couple this with the difficulty of scrolling through a ton of files with just a knob. I'm thinking this is okay. Basically, don't put 100 files on an SD card. What do you think?
To err is human. Fortune favors the monsters.
Maybe add a button and use a tree structure for the files, where you can drill down into; (and I don't know a damn thing about it...but) drum beats chill jazzy moody etc.
The most expensive tool is a cheap tool. Gareth Branwyn JaxCoder.com
-
Maybe add a button and use a tree structure for the files, where you can drill down into; (and I don't know a damn thing about it...but) drum beats chill jazzy moody etc.
The most expensive tool is a cheap tool. Gareth Branwyn JaxCoder.com
That's not possible. MIDI files aren't classified that way, and to impose such a structure would require the user to do so in some way, such as using folders. I'm not scanning subfolders due to the complexity, primarily of navigating folders using nothing but a button and rotary encoder. This isn't for tech savvy folks.
To err is human. Fortune favors the monsters.
-
That's not possible. MIDI files aren't classified that way, and to impose such a structure would require the user to do so in some way, such as using folders. I'm not scanning subfolders due to the complexity, primarily of navigating folders using nothing but a button and rotary encoder. This isn't for tech savvy folks.
To err is human. Fortune favors the monsters.
Gotcha, only other way would be paging.
The most expensive tool is a cheap tool. Gareth Branwyn JaxCoder.com
-
Gotcha, only other way would be paging.
The most expensive tool is a cheap tool. Gareth Branwyn JaxCoder.com
My current solution is to simply make the user wait to load it all. It doesn't handle a lot of files really well anyway because it has to load them all into memory first. The reason is the rotary encoder can be turned much faster than the SD card reader can read file info. So I have to prefetch everything. I have about 320kB free at that point, so it's not terrible, but it can't be excessive. So my current idea is - MIDI files in the root directory only, and then just don't put a ton of them there. It's actually better to use multiple SD cards. If you only have one file on it it will load it automatically so you can punch sets in an out.
To err is human. Fortune favors the monsters.
-
That's an interesting idea. I'll consider it. My main concern with it is if the list isn't done loading it will be hard to tell when it's done and you've reached the end or if there's more to go. I guess I can squeeze an indicator on there but the screen is very small. Also it displays only one file at a time due to the size of the screen, and displaying information about each file, so there's no "list" to scroll. Plus scrolling is out of the question for performance reasons the way these little gadgets work.
To err is human. Fortune favors the monsters.
The indicator is very important for perceived performance - if you can quickly count the files, I assume you can even show a percentage or similar? Maybe if you detect more than a reasonable amount of files, you can start by displaying a text saying "This will take a long time, do you want to continue" (well, something shorter probably). If you are really fancy, you can start the loading in the background while displaying the message so the time until they react (if they react) is not wasted. If they just insert the SD card and throw it on the table without paying attention - at least it will then have finished loading when they come back from lunch instead of just sitting waiting for them to press the button.
-
The indicator is very important for perceived performance - if you can quickly count the files, I assume you can even show a percentage or similar? Maybe if you detect more than a reasonable amount of files, you can start by displaying a text saying "This will take a long time, do you want to continue" (well, something shorter probably). If you are really fancy, you can start the loading in the background while displaying the message so the time until they react (if they react) is not wasted. If they just insert the SD card and throw it on the table without paying attention - at least it will then have finished loading when they come back from lunch instead of just sitting waiting for them to press the button.
Yeah I probably could put an indicator. Do you want to continue is a little tricky, as taking input is always a bit involved when you're dealing with limited user input devices.
To err is human. Fortune favors the monsters.
-
My current solution is to simply make the user wait to load it all. It doesn't handle a lot of files really well anyway because it has to load them all into memory first. The reason is the rotary encoder can be turned much faster than the SD card reader can read file info. So I have to prefetch everything. I have about 320kB free at that point, so it's not terrible, but it can't be excessive. So my current idea is - MIDI files in the root directory only, and then just don't put a ton of them there. It's actually better to use multiple SD cards. If you only have one file on it it will load it automatically so you can punch sets in an out.
To err is human. Fortune favors the monsters.
:thumbsup:
The most expensive tool is a cheap tool. Gareth Branwyn JaxCoder.com
-
Yeah I probably could put an indicator. Do you want to continue is a little tricky, as taking input is always a bit involved when you're dealing with limited user input devices.
To err is human. Fortune favors the monsters.
"Click to continue". It's not like saying "no" really means anything they can't express by taking out the SD card. The important thing is that they are told what they can do to avoid it being so slow. Do not expect users to think twice about filling an SD card with old data if you do not tell them the problems it will give.
-
So I have an app that's designed to run on a piece of hardware intended for musicians, who are not tech savvy. They also use equipment that can produce corrupt files, although that's not exceedingly common. My software boots and reads an inserted SD card. Currently during this process it loads each MIDI file and scans through its entire contents to determine if its valid before adding it to the list of available files. That way, corrupted files do not appear in the list. It also means I can display more information about each file. Once loaded, you scroll through the file list with a small rotary encoder (a knob basically for those of you that don't know what one is) The issue is this: The title screen can take some time to load. It's not terrible with a dozen files, but more than that and it starts to be like "hurry up!" Couple this with the difficulty of scrolling through a ton of files with just a knob. I'm thinking this is okay. Basically, don't put 100 files on an SD card. What do you think?
To err is human. Fortune favors the monsters.
For your intended users, is it a reasonable expectation that they can't put 100+ files on the SD card?
-
For your intended users, is it a reasonable expectation that they can't put 100+ files on the SD card?
I think so. In practice, this is a little performance box, and scrolling through that many files is not really reasonable. Anything after a dozen and they'll get annoyed just because all you have to work with is a knob and a button. It's not like PC dev, unfortunately. The UI is severely limited by a very limited input interface - tiny screen, no keyboard or mouse. no scrolling because it's too slow. Because of that, I think a user at least once they are familiar with using the thing, isn't going to be put out by not carrying their entire catalog of MIDI sets on a single SD card. In fact, it's kind of optimized for one per SD-Card, such that when it finds just one file it will open that one and start up without prompting. That's because eventually I'll probably make it so you can punch in and punch out SD cards on the fly, but for now i don't have the right hardware for that. It's not hard to get it though, i just haven't yet.
To err is human. Fortune favors the monsters.
-
So I have an app that's designed to run on a piece of hardware intended for musicians, who are not tech savvy. They also use equipment that can produce corrupt files, although that's not exceedingly common. My software boots and reads an inserted SD card. Currently during this process it loads each MIDI file and scans through its entire contents to determine if its valid before adding it to the list of available files. That way, corrupted files do not appear in the list. It also means I can display more information about each file. Once loaded, you scroll through the file list with a small rotary encoder (a knob basically for those of you that don't know what one is) The issue is this: The title screen can take some time to load. It's not terrible with a dozen files, but more than that and it starts to be like "hurry up!" Couple this with the difficulty of scrolling through a ton of files with just a knob. I'm thinking this is okay. Basically, don't put 100 files on an SD card. What do you think?
To err is human. Fortune favors the monsters.
Don't allow "scrolling" while files are being imported. Just show the progress of the import and maybe allow cancelation.
-
So I have an app that's designed to run on a piece of hardware intended for musicians, who are not tech savvy. They also use equipment that can produce corrupt files, although that's not exceedingly common. My software boots and reads an inserted SD card. Currently during this process it loads each MIDI file and scans through its entire contents to determine if its valid before adding it to the list of available files. That way, corrupted files do not appear in the list. It also means I can display more information about each file. Once loaded, you scroll through the file list with a small rotary encoder (a knob basically for those of you that don't know what one is) The issue is this: The title screen can take some time to load. It's not terrible with a dozen files, but more than that and it starts to be like "hurry up!" Couple this with the difficulty of scrolling through a ton of files with just a knob. I'm thinking this is okay. Basically, don't put 100 files on an SD card. What do you think?
To err is human. Fortune favors the monsters.
find a musician like and ask this question, you will have first hand feedback...
diligent hands rule....
-
find a musician like and ask this question, you will have first hand feedback...
diligent hands rule....
I have some pretty tiny mp3 players (the size of a thumb drive); with 100's of songs. I'd review how they did it. Mostly single thumb actions.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
-
So I have an app that's designed to run on a piece of hardware intended for musicians, who are not tech savvy. They also use equipment that can produce corrupt files, although that's not exceedingly common. My software boots and reads an inserted SD card. Currently during this process it loads each MIDI file and scans through its entire contents to determine if its valid before adding it to the list of available files. That way, corrupted files do not appear in the list. It also means I can display more information about each file. Once loaded, you scroll through the file list with a small rotary encoder (a knob basically for those of you that don't know what one is) The issue is this: The title screen can take some time to load. It's not terrible with a dozen files, but more than that and it starts to be like "hurry up!" Couple this with the difficulty of scrolling through a ton of files with just a knob. I'm thinking this is okay. Basically, don't put 100 files on an SD card. What do you think?
To err is human. Fortune favors the monsters.
I have some pretty tiny mp3 players (the size of a thumb drive); with 100's of songs. I'd review how they did it. Mostly single thumb actions.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
-
So I have an app that's designed to run on a piece of hardware intended for musicians, who are not tech savvy. They also use equipment that can produce corrupt files, although that's not exceedingly common. My software boots and reads an inserted SD card. Currently during this process it loads each MIDI file and scans through its entire contents to determine if its valid before adding it to the list of available files. That way, corrupted files do not appear in the list. It also means I can display more information about each file. Once loaded, you scroll through the file list with a small rotary encoder (a knob basically for those of you that don't know what one is) The issue is this: The title screen can take some time to load. It's not terrible with a dozen files, but more than that and it starts to be like "hurry up!" Couple this with the difficulty of scrolling through a ton of files with just a knob. I'm thinking this is okay. Basically, don't put 100 files on an SD card. What do you think?
To err is human. Fortune favors the monsters.
I have no solution, just a little story: Some years ago, I bought myself a handheld digital recorder (for those who care: a Zoom H4n), and equipped it with a 32 GByte card so I didn't have to shuffle lots of cards around. It is a nice little device, can record plain PCM and MP3 in high quality, even 4 channels. The only thing that frustrated me was the extremely long boot up time - more than a minute and a half before any control could be operated. Either, the recording had to be well planned in advance, or the recorder had to kept 'on' continuously, draining the batteries. A couple of years ago, I made some recordings to an SD card of a friend of mine - a 2 GB card. To my surprise, the recorder booted up a lot faster. At the bottom of a box of old stuff, I found the very first SD card I ever bought, a 256 MB one, and now the recorder boots up in 12 seconds, rather than 95 seconds! It makes noticeable difference if there are lots of data on the card (the Zoom pre-initializes a directory structure with approx. 40 directories when it formats the card; it is unconditionally there). If I replace the 256 MB card with the 32 GB one, it goes back to eight times as slow boot up - the recorder hasn't been 'cured', the boot time is tied to the card size. Putting a hundred recordings on a card does not slow it down further. I have no idea what the Zoom is doing to the card; even though flash cards are fast, it can't possibly do any testing of a full 32 GB in 95 seconds. The size of the directory structure is exactly the same on a small and a large card. So what is it doing with the 32 GB at boot up? I was lucky to find a small pile of 256 MB cards on a web shop trading used electronics - my local computer shop couldn't help me. So now I have cured the major problem with my recorder, at the price of having to shuffle cards.
-
I have no solution, just a little story: Some years ago, I bought myself a handheld digital recorder (for those who care: a Zoom H4n), and equipped it with a 32 GByte card so I didn't have to shuffle lots of cards around. It is a nice little device, can record plain PCM and MP3 in high quality, even 4 channels. The only thing that frustrated me was the extremely long boot up time - more than a minute and a half before any control could be operated. Either, the recording had to be well planned in advance, or the recorder had to kept 'on' continuously, draining the batteries. A couple of years ago, I made some recordings to an SD card of a friend of mine - a 2 GB card. To my surprise, the recorder booted up a lot faster. At the bottom of a box of old stuff, I found the very first SD card I ever bought, a 256 MB one, and now the recorder boots up in 12 seconds, rather than 95 seconds! It makes noticeable difference if there are lots of data on the card (the Zoom pre-initializes a directory structure with approx. 40 directories when it formats the card; it is unconditionally there). If I replace the 256 MB card with the 32 GB one, it goes back to eight times as slow boot up - the recorder hasn't been 'cured', the boot time is tied to the card size. Putting a hundred recordings on a card does not slow it down further. I have no idea what the Zoom is doing to the card; even though flash cards are fast, it can't possibly do any testing of a full 32 GB in 95 seconds. The size of the directory structure is exactly the same on a small and a large card. So what is it doing with the 32 GB at boot up? I was lucky to find a small pile of 256 MB cards on a web shop trading used electronics - my local computer shop couldn't help me. So now I have cured the major problem with my recorder, at the price of having to shuffle cards.
Well at least you know my pain. I've since added a progress tracker "loading 1 of 13" for example. It helps.
To err is human. Fortune favors the monsters.
-
I have some pretty tiny mp3 players (the size of a thumb drive); with 100's of songs. I'd review how they did it. Mostly single thumb actions.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
It might cache. I could theoretically do that.
To err is human. Fortune favors the monsters.
