Design a Panorama UI

[bzar]

Panorama (git) (repo) (beta thread)


Some of you might already be familiar with Panorama, the user interface (UI) engine I'm doing with dflemstr based on QtQuick, QML, and plugins that extend its abilities. It's not a UI itself, but provides a base to build rich UIs on top of. Currently it supports listing and launching applications, showing system information like free SD card space and battery state, pandora controls and a preliminary support for package management using Cloudef's libmilky package management backend that utilizes the repository spec, so it's compatible with Milkshake's repo.openpandora.org. To see it in action, check out my youtube channel or dflemstr's early videos on vimeo. The package manager plugin (milky-plugin) can queue operations and run several install/remove/upgrade operations at once, my test UI just doesn't use that as it concentrates on simplicity.


Now, I'm not a UI or interaction designer. I don't know what kind of UI would be desirable for anyone else but myself. That's why I'm asking you for help. After I'm done with my current task (milky-plugin and MilkyTest UI), I'd like to try and do a UI based on what YOU want. Specify me a UI that the community wants and I will try my best to implement it. I'm not an artist, so any images need to be done by someone else, but I can do the coding, animation and interaction as far as QML allows. Any gradients and stuff like that is of course easy peasy . What I'd like the UI to have is both package management and a launcher. These can possibly be combined if so desired, I haven't looked into it yet. Check the videos for examples of both. At this point I'm not looking for feature requests for the engine or its plugins, we have plenty of features we intend to add. What I'm looking for is a visual representation of the UI and interactivity descriptions. Layout pictures, sketches, control specifications, art. In short, a UI design.


As I'd like the opinion of the community on this, it will be something like a popularity contest. If there's enough people wanting me to do a specific UI, I'll try. I can't do many, because there's still a lot of other stuff to do in panorama, and doing UIs takes time. But as I'm doing this for you guys to use, I'd like you to have something you want, not just something I happen to make


Discuss, collaborate, and tell me what to do


PS: Milky-plugin and MilkyTest UI will take some time so I won't jump right at this. I just wanted to start this early so we may have something I can work on when I'm done with them.


EDIT: Added repo link

 

[ProfChaos]

I would like to see a UI similar to the psp's and ps3's xmb. I like the idea of a menu that can access both applications and media in the same place rather then launching the movie player and whatnot separately.

 

[jakman4242]

So is this supposed to be a sort of UI shell for Pandora?

 

[vadsamoht]

So is this supposed to be a sort of UI shell for Pandora?

No, for the package manager plugin.

 

[bzar]

UI shell in the way minimenu is, yes. The package management is just one part of it. The MilkyTest UI in the videos only has package management, but that's because it's my test UI for the package management plugin.

I would like to see a UI similar to the psp's and ps3's xmb. I like the idea of a menu that can access both applications and media in the same place rather then launching the movie player and whatnot separately.

That would require a new feature (media player capabilities). Certainly not impossible with panorama with a suitable plugin, but a bit out of scope for this UI.

 

[Christoph.Krn]

Now, I'm not a UI or interaction designer. I don't know what kind of UI would be desirable for anyone else but myself. That's why I'm asking you for help. After I'm done with my current task (milky-plugin and MilkyTest UI), I'd like to try and do a UI based on what YOU want. Specify me a UI that the community wants and I will try my best to implement it.

I'm not a UI and/or interaction designer either, but I'm interested in it and I do know that it's not a good idea to mix up an interface based on what people say. More often than not, what people say they want in a GUI is not actually what they want in a GUI. Simply following a "most votes win" approach won't yield the desired results (that is, if you desire above-average results). To say it in oversimplified words, you have to find out what people want based on how they actually use software.


I had already provided some thoughts that I had made about a combination of a package manager and launcher, which you might or might not have seen already. (I have to apologize for the large amount of text in the posts and its links. The explanations have become bloated because I had failed to explain the idea right the first time.)


Feel free to use any of the ideas and information therein, but be aware that now that I have an actual Pandora, I would change some things in beauty-get if I were going to implement it (which I won't, since a repository as well as a package manager already exist). Most importantly, I would put more focus on making it easily usable with the Pandora's physical gaming controls, putting less emphasis on touch screen use.

 

[MichaelXX2]

So this new UI of yours can't run a media player? Then why use it?

 

[bzar]

Christoph.Krn: True, true. The problem with the "usual" usability study route here is that you're all around the world , and I don't have enough suitable people nearby to see how people use my interfaces, so I'm just about my only data point. My only usability feedback comes from people trying panorama or just seeing videos of it (less than optimal). So I figured I'd get some bearing on popular opinion, see how that works, then polish if needed. I just want more input, and because I can't get any actual usability data or have an experienced UI/interaction designer at hand this seemed like the best option. Another reason is that I'm also not an artist, so I'd like some help with the visual style and graphics. And last but not least, I want to engage the community into making something collaboratively, rather than me just spewing out stuff I happen to make.


Your beauty-get seems to have the right idea for finding new stuff to try out. I'd like to implement something like that, but in my opinion demo video and rating support should come from the repository , possibly even a list of "featured" applications (I'd say these would be optional features of the repo spec). I have a few ideas to help find new applications, like previewpic mosaics and stuff, something akin to amazon's window shopper.


I intend to support (in my interfaces) both the touch screen and gaming controls, as it's not a lot of work with panorama. But I agree that putting weight on touch screen use is not a good idea. It's nice eye candy, but not really usable in every situation in the long run.

So this new UI of yours can't run a media player? Then why use it?

It can run a media player the same way minimenu and xfce can. As a separate application.

 

[jakman4242]

I don't own a Pandora, so I don't know how the touch-screen experience is on it, but you really should embrace all input methods of the Pandora if you want to get the most out of the system.


Touch screen UI is easy to manage. A few simple concepts go a long way.


- No right click menus.(Instead, button-based context menus)


- Drag-to-scroll


- All buttons at least 0.5in wide/high. Makes them easier to press.


Ideally, it should be easy to navigate the system each way. If you want a great reference for marrying key and touch input, look at the 3DS.

 

[bzar]

^ Check the videos in my youtube channel (link in the top post). So far I have done so, but of course these are important to keep in mind for any UI for pandora.

 

[jakman4242]

I did! And your UI looks great, by the way.(well, graphically it could be better, but the layout it great.)


I particularly liked the screenshot view/slideshow. Very well done.


And also, at first I wasn't aware that the top-left button acted as a sort of filter switch. I had no idea it was a button, actually. Not sure how to remedy that without changing the UI, though. A uniform "button" look throughout your UI definitely would. Aside from that, maybe switch it to a sort of tabbed view? Not a huge issue, though, I don't think.

 

[bzar]

Oh, pardon me then .


Yep, some sort of "I'm an active element! Click me!" hint would be good. I haven't quite figured out what it should be like for that UI so far. The whole toolbar on the top looks... flat. Maybe I could try to pop the buttons up a bit with some shading.

 

[Christoph.Krn]

Christoph.Krn: True, true. The problem with the "usual" usability study route here is that you're all around the world , and I don't have enough suitable people nearby to see how people use my interfaces, so I'm just about my only data point.

Okay, I see what you mean. I was afraid that you could implement each and every feature that people vote for into a single interface, no matter if the combination of these features was a good idea. That could have easily led to various usability hell scenarios, such as various usage modes, or duplicate graphical interfaces within one software that are used to basically accomplish the same thing. Maybe I misinterpreted what you wrote.


-----

Your beauty-get seems to have the right idea for finding new stuff to try out. I'd like to implement something like that, but in my opinion demo video and rating support should come from the repository , possibly even a list of "featured" applications (I'd say these would be optional features of the repo spec).

Keep in mind that I had started working on this long before there even was any PND-specific repository specification (or so I assume), so making a repository specification with support for voting as well as videos and preview videos was part of the plan since it fit with the general idea. With that being said, it goes without saying that I agree with you that theses things should be in the repository (but I do think that accomplishing a bidirectional voting and comment support for native clients would be a good thing).


However, the most important part about the idea of beauty-get is that ideally, it should not be possible to recognize that the local software is depending on data that comes from a server. It really encourages people to use a software if there is no lag whatsoever. If you read the notes in the spoiler entitled "Work in progress comments and ideas on this work in progress mockup:" at http://www.gp32x.de/board/index.php?/topic/50747-appstore-look/page__view__findpost__p__793248 , you can see that I put emphasis on giving as much information per <time> and <interaction> as possible (again incorporating the repository specification, as well as specific server-side considerations).


Imagine an end user using the interface as seen in http://www.youtube.com/watch?v=_DIEbxzRqIg. The user would not be encouraged to open up the screenshots of any software out of sheer curiosity or simply because it's fun to use the interface, since it would require more time for the screenshots to load than what would be deemed worth for a quick glimpse, unless the description and/or name of that particular software had already sounded interesting enough to make the user perceive that tapping the thumbnail is worth the waiting time. In other words, the quality of the technical realization of a preview picture function alone does not necessarily give users a huge enough benefit compared to what already exists or could exist.


See, I told you I messed up getting the idea of beauty-get across. You really have to read all the texts, and even then you might not even get a glimpse of the idea. Imagine a user interface that allows you to swiftly swipe through small versions of all preview pictures without the need to "open up" something and has hardly any perceivable loading times, without losing any of the features that you have grown fond of, and you get the basic idea of beauty-get.


-----

And also, at first I wasn't aware that the top-left button acted as a sort of filter switch. I had no idea it was a button, actually. Not sure how to remedy that without changing the UI, though.

What about removing the button that is currently in the top-left corner and putting status buttons labeled "Installed", "Not installed" and "Upgradable" into the screen that pops up after you tap "All" (the category screen) alongside the category buttons?


I'm aware that this sounds rather arbitrary at first. But what if you allowed users to enable and disable every button separately instead of allowing them to just tap a single one? Again, this is basically what I intended for beauty-get. This way, the user could enable, say, the buttons "ActionGame", "ArcadeGame" and "Installed" at the same time to only show all installed action and arcade games, or "Calendar", "Email", "Education", "Calculator" and "Not installed" to quickly search for installable applications for a specific workflow. To a developer, statuses and categories are completely different things, but to an end user, they are both mainly just ways to say "That one, please!", so it makes sense to put them together.


Actually, with beauty-get I went one step further, making these buttons (I call them "regex buttons") regex enabled, with the label of each button being merely an additional description to underlying regular expressions, so that the user could add custom buttons by providing the regular expressions and a description for the label. This would enable users to, for instance, create a button that says "Good file managers", with underlying regular expressions that say to get all applications from the "FileManager" category where (rating > 85). You could put a bar a gear icon into the right-hand end of each customizable button, and when the user activated that icon (e.g. by tapping it), a single, large text input field would pop up that would accept the full configuration for the button as if the whole configuration of that button was inside a single text file (including the regular expressions, the label, the color of the button and optional icon and background pictures in base64). This would make it easy for people to share buttons on the forums by copy-and-pasting the text over (which would cause tutorials to appear eventually).


-----

[...] possibly even a list of "featured" applications (I'd say these would be optional features of the repo spec). I have a few ideas to help find new applications, like previewpic mosaics and stuff, something akin to amazon's window shopper.

Hmm... how should the featured items be chosen (i.e., WHO should chose them)?

 

[milkshake]

if needed and or agreed apon I can provide thumnails (I have them in use on the site anyway 150px x 90px) via the repo spec too but this would need to be agreed as it would add overhead to the json

 

[bzar]

Okay, I see what you mean. I was afraid that you could implement each and every feature that people vote for into a single interface, no matter if the combination of these features was a good idea. That could have easily led to various usability hell scenarios, such as various usage modes, or duplicate graphical interfaces within one software that are used to basically accomplish the same thing. Maybe I misinterpreted what you wrote.

Of course I hope the end result will be a usable one, and will offer my limited usability knowledge whenever I see a need.

(explanation of beauty-get)

I had a system that showed all the preview pics in the package details part and even preloaded them before the user even decided he wanted to look at the details. This resulted in saturation of the WLAN connection and ultimately even more lag. This is mostly because I don't have a pre-downloaded cache of the images, but download them at runtime and cache them only per session. If I understood correctly, you'd store all the images locally (otherwise you can't get rid of loading times due to network speed), and sync them to the repo's content when the package data is synced? That sounds like a really big operation, finding out and downloading all the changed preview pics.


Or I just misunderstood again

(about the status and category buttons)

Fun fact, the category filtering in Panorama works exactly like that , but in MilkyTest the filters are fixed to one status, one category and one free text. This would not be hard to change to a customizable number of filters though. Nice idea


The unified status filtering you propose would even be quite easy to implement, though at the time I prefer my solution, as the three states of the status button conform to the three main use-cases. Your solution is more flexible, but ultimately I feel it's more confusing. I could however make them three "tab" style buttons ("Install" "Remove" "Upgrade") instead of a status selection. Could be more intuitive.


Selecting multiple categories is a good idea though, as is the custom category filters. I thought of adding them too and also hiding categories so the user can- for example -replace all the *Game categories with a single "Game" one.

Hmm... how should the featured items be chosen (i.e., WHO should chose them)?

I think this would be up to the repo maintainer, or person(s) appointed by him/her. Kinda like the game of the week stuff in pandorapress, it's at the publisher's discretion.

 

[chosen]

I had an idea. How about users can register all their ROMs for all emulators with a Panorama UI, entering them into the same category system as native apps, so it's one consistent UI to select from, for all your games including ROMs. The ROMs when displayed in the UI would have an overlaid image in the corner to show which system they are for. The user can browse a combined view of every single game on their system, or display only 'apps', i.e. ROMs, for a single platform to select from. When selected, ROMs should launch with the appropriate emulator, that can be configured per ROM, i.e. different ROMs for the same console/computer system could launch different emulators, for compatibility, and pass custom arguments to avoid having to set up anything again and to make a seamless user experience, e.g. resolution and core for UAE4ALL. Could perhaps have a database of ROM info, keyed off MD5s to centralise and share a default good configuration within the community. This database could also apply to launching native apps with different data/level packs, or launching from multiple apps within a PND or passing arguments to apps. The database is maybe a wider idea than just Panorama and could be applied to XFCE menu, but I think Panorama is the best place to start and develop this concept. A few settings, rather than being ROM dependent, are global user preferences across one or all systems, for example fullscreen stretching.


Could even detect compressed ROMs and decompress them automatically, or list files and locations for game data, and anything like that for consistent simplicity and to make everything 'just work' for the 'casual gamer', with the objective of mass market take-up of the Pandora.


Some of these features might be better implemented into the emus/apps, we would need to create a standard for these to conform to. Alternatively if it's possible to bring these things out of the apps and into the launcher configuration it makes it easier for the community to contribute.

but a topic for another thread

Sorry Wasn't suggesting you implement this immediately. Was getting my spontaneous ideas down while they were fresh, sparked by reading this thread.


I'll move this post elsewhere, once I work out where is best. I haven't found an appropriate thread yet so I'm guessing a new thread is in order(??) PM me if you know where is best.

 

[bzar]

A ROM data model/launcher is implementable as a plugin the same way the package management and application launching are, but it's a whole new (and quite large) feature. It might be a good addition to panorama's plugins, but it's not exactly what this thread is for. This thread is for designing a UI that makes use of the current features in panorama (application launching, package management, system information). It's more about how the UI works than what it does.


I don't mean to slam you down. That's a good idea and definitely on my list now, but a topic for another thread. As you say, it would also require some specification. What information is held for ROMs? Where does it come from? How are the emulators defined and linked to the files? There are probably good answers to many of these in the other ROM launcher threads. Anyway, I think this warrants a separate conversation when someone has the time to dig into it.

 

[chosen]

I've tried to have an idea that's relevant to the thread. For tabbed UIs how about a transition when changing tabs?


I understand the rendering engine is web based currently for most of these UIs, restricting things to scaling, position offset, fading and layers, i.e. no 3D.


Most basic, cross-fade.


More advanced: The new tab page would fade in on a layer from behind and scale up from 0, moving outward in a spiral, while the old one fades out in front scaling above window side.


Or is could shrink to a small size and bounce along the bottom of the screen and off to a side, or the same in reverse for the new page. New one could bounce in from one side while the old bounces out to the other.


Or enter at a large size, scroll quickly across or another the large area (or another motion e.g. circular), then shrink into place.


Perhaps the the animation can reverse depending on the order of the tabs.


Transition would need to be pretty quick, don't want to be waiting.


If you think this is worth exploring, I'll try to find time to create a mockup in jQuery.

 

[darfgarf]

More advanced: The new tab page would fade in on a layer from behind and scale up from 0, moving outward in a spiral, while the old one fades out in front scaling above window side.


Or is could shrink to a small size and bounce along the bottom of the screen and off to a side, or the same in reverse for the new page. New one could bounce in from one side while the old bounces out to the other.


Or enter at a large size, scroll quickly across or another the large area (or another motion e.g. circular), then shrink into place.

that sounds utterly horrific


especially so if it blocked input while the animations played out, but hey that's the advantage of a system like this, would be rather simple to turn off the animations

 

[bzar]

It seems there's some... misunderstanding of what I'm asking. Panorama can do a LOT of different kinds of UIs. They don't have to resemble anything I've shown so far. You can have application categories on flickable pages, icons moving in a 3d circular path, packages shown as a mosaic of previews or pretty much anything. As long as it's 2D and not horribly complex, I'd say it's possible. Go wild, think outside the UIs you've seen so far. Think about a use case, like launching an application, browsing applications or finding packages. How do you want the UI to tell you about updates? What should the different pandora buttons do? At this point the UI is going to do application launching, package management, system information and I can throw in a simple web browser (the webkit based WebView is just another element in QML, easy to add). This is what it can do at this point, but how do you want to do these things with it? What do you want it to look like? What kind of views should there be, how do you move between them? What parts should be customizable with settings?


I hope these help you see what I mean by a UI design.