Adding key bindings

DrZiplok · 08-21-2007, 03:57 AM

Dave,

Also, since I'm hijacking, I'd really like to see keybindings available for every UI element. This would make driving the bulk of the UI 'blind' with a Nulooq a very doable thing...

Thanks! Let me know if there's more info I can help with.

= Mike

bpwned · 08-21-2007, 08:42 AM

Not only should every UI element be accesable with a keybinding, I think there should also be an "intelligent" tab order for every element, so that one can use a rotary controller. (Turn right -> next element, turn left -> previous element, press -> click; since everything should be doable with simple clicks on certain elements, it then should be possible to control CFE completely with a Powermater or something similar)

iamgnat · 08-21-2007, 09:42 AM

Quote: Originally Posted by DrZiplok

Also, since I'm hijacking, I'd really like to see keybindings available for every UI element.

This is a bit easier said than done

I do plan to look into key bindings once I start on adding accessibility/remote control functionality, the the plugin architecture offers a challenge to this.

Because the app uses plugins, it can only provide bindings for the buttons and elements that it controls directly. It would be up to the plugin programmer to provide bindings for their elements. Of course the obvious issue with that is that at some point you will run into conflicts.

The other issue is the plugin buttons themselves (on the Menu screen). Unlike the QuickSlots which are "physical" buttons built into the NIB file, the Plugin Buttons are dynamically created at runtime based on the number of plugins that are loaded. While it is possible (at least i'm pretty sure) to add the key binding via code, that offers an even greater potential for conflicts.

Believe me, the sooner I can get rid of my touch screen, the happier i'll be

But I want to make sure that the solution that is implemented has the lowest chance of failure and weird results as possible.

I'm open to any and all suggestions, and if you know more about key bindings than I do (0 beyond the basic concept and IB implementation) please correct any incorrect impressions I may have.

Thanks,
-dave

iamgnat · 08-21-2007, 10:03 AM

Quote: Originally Posted by bpwned

Not only should every UI element be accesable with a keybinding, I think there should also be an "intelligent" tab order for every element, so that one can use a rotary controller. (Turn right -> next element, turn left -> previous element, press -> click; since everything should be doable with simple clicks on certain elements, it then should be possible to control CFE completely with a Powermater or something similar)

Much like the key bindings, there are some issues with this.

While it is possible to setup tabbing between elements in different views, I haven't done it yet so I don't know the details. And I imagine handing off tab control to a plugin and (hopefully) getting it back would be another challenge.

On the aesthetic, it would require adding focus rings to the elements so you know where you are. I'm not sure how I feel about that...

On a practical side, if we use the existing UI as the example and look at the iTunes plugin. Let's assume that the tab order is top to bottom and left to right (ugh, would have to change this logic for the right hand swap..) for the CFE portion (the QuickSlots, Menu, Vol, Mute buttons) of the screen and left to right and top to bottom in iTunes (so the Mute and Repeat buttons are the last elements respectively). Now let's say you've tabbed over to the Next Track button and the volume is way off (high or low) and you need to adjust it. That's 5 advancing tabs (assuming you only have one plugin loaded, but could be 7) or 8 retreating to get to the volume control. And if you are working with a plugin that has more UI elements, it could be much worse.
At best I think it shows the need for multiple inputs, at worst I think it shows that it is a horrible way to navigate a UI when the number of elements are out of your control

I think the real answer is that there will need to be support for multiple access options (e.g. plugins adding control, AppleScript, "mouse", tabbing, key bindings, etc...) so that by mixing and matching you can get the functionality you desire.

-dave

DrZiplok · 08-21-2007, 02:14 PM

Dave,

There are a couple of things to consider here, but the first is to jet back for a second and think a bit about your overall UI design.

I would encourage you to be very careful about having too much on the screen, or too many actions that have to be decided between at any given point in time.

It's not unreasonable to have a considerable degree of modality in your UI, as long as you think carefully about how to navigate it. Having bindings for every plugin active at the same time does not seem like a good idea to me. Having a way to get quickly to a point where a mini-app/plugin can be activated (think Dashboard, or the iPhone home screen) sounds much better.

One of the biggest gripes I have with every car player UI to date is that they hopelessly clutter the display with crap. If I'm in the middle of selecting something from a list, wasting 50% of the display with the current time, temperature, a mini audio spectrum display, fifteen buttons and the application's logo is just silly. I want to see the list, some way to back out of making the selection, and a simple reminder of what exactly it is that I'm doing...

If you're not familiar with the Nulooq, you should check one out. It's roughly analagous to 9 buttons, a rotary encoder and a three-position momentary switch. The software allows you to bind arbitrary keystrokes to each of these operations, and repeat/hold them in a variety of ways.

If you're keeping to a fairly modal design, it should be possible in any given context to do something pretty sane with the controller.

= Mike

iamgnat · 08-21-2007, 03:18 PM

Quote: Originally Posted by DrZiplok

I would encourage you to be very careful about having too much on the screen, or too many actions that have to be decided between at any given point in time.

I absolutely agree. There is one main problem I have, I can't control what a plugin developer does (beyond meeting my protocol definition). So there are two major UI issues that I have to be concerned with.

The first is that I want to make sure that the user can quickly get around the application regardless of what the plugin does. This I can manage to a degree and is what I accomplish with the controls on the left.

The second is that I have no control over what a plugin does with it's UI. If they want to cram 100 UI elements onto a single view, there is nothing the application can do about it.

My iTunes plugin is actually a good example, there is no reason that the top line of buttons (playlist control) needs to be there the whole time. I just did it as a quick and dirty job since that is how I normally listen to music. The proper answer would be to have a single button on the screen that would pop a new view to let you select playlists, albums, artist, etc.. (I do want to do that, but I need some additional UI elements first

).

Quote:

Having bindings for every plugin active at the same time does not seem like a good idea to me.

I absolutely agree, and that's one of those things that I don't know about how key bindings work. I know if you have separate windows, then only the active window gets the action. But what about a view that has been loaded but is currently not visible? I would assume that the correct thing happens, but I need to play with it to find out.

Quote:

Having a way to get quickly to a point where a mini-app/plugin can be activated (think Dashboard, or the iPhone home screen) sounds much better.

I would agree, but I would take it a step further that frequently used (clicking buttons or just seeing the displayed information if it changes) should be easily available if not available all the time. In both your examples, it requires functionality outside of just using a touch screen (hot corners are a PITA on a TS

) which is the only simple interaction many of us have right now (though I agree a more controllable app would make it easier to use other solutions).

Quote:

One of the biggest gripes I have with every car player UI to date is that they hopelessly clutter the display with crap. If I'm in the middle of selecting something from a list, wasting 50% of the display with the current time, temperature, a mini audio spectrum display, fifteen buttons and the application's logo is just silly. I want to see the list, some way to back out of making the selection, and a simple reminder of what exactly it is that I'm doing...

I agree. For anything I develop, I will always make the effort to only display exactly what is needed for the action you are performing or are most likely to perform.

Quote:

If you're not familiar with the Nulooq, you should check one out.

I know of them, but haven't played with one in person.

Quote:

If you're keeping to a fairly modal design, it should be possible in any given context to do something pretty sane with the controller.

That's the line i'm thinking. Rather than bind keys, tabs, etc.. to specific functions, my basic idea is to have plugins (there would be some reserved actions for the app itself) register for messages they want, then they can do what ever they want when they get them. Then, and more importantly, you could write a plugin to receive any type of input you wanted and then send the desired message off to the controller that would then pass it on to the correct plugin.

-dave

Bugbyte · 10-19-2007, 10:08 AM

In a different thread, you said to post suggestions in relevant threads. Here's mine.

So far, I like the simplicity of CFE but I'd really like it if I could control it using my Powermate. The simplest way to do that is to allow key bindings.

Understanding the issues you've discussed in this thread already, can't you define certain keys to perform certain actions like volume up/down, jump between plug-ins, and reserve them?

The best thing about QCar is that you can easily navigate to just about anything using a rotary controller with limited functions. I really like that feature.

There's one of my 2 cents!

mustanglou · 11-10-2007, 02:43 PM

FWIW, I still use my powermate to control things like volume, play/pause, next song, and previous song. This is handled by applescripts in Butler. Eventually, it would be nice to have it all handled by CFE but I understand it's going to take some time for the UI to be hammered out.