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.
Originally Posted by DrZiplok
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 ;)).
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.
Having bindings for every plugin active at the same time does not seem like a good idea to me.
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).
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 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.
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 know of them, but haven't played with one in person.
If you're not familiar with the Nulooq, you should check one out.
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.
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.