Sorry that I'm not providing the full UI design that you are looking for, at this time, just throwing a few ideas about. Hopefully someone is going to come forward soon with something decent.
One thought I had today, instead of a separate sidebar of tabs, these could be incorporated into the icon/item hierarchy. So at the top level would be the various sections, equivalent of the tabs, so more minimalist visually. There would be an 'up to parent' item (with a key shortcut), within the sub areas to get back up, or better this is the one button always on screen, like Magma's back button. There could be deeper levels if this suited uses i.e. file browsing. I'm thinking game button B to go into stuff/run and A to go up in the hierarchy, with X and Y for scrolling through. When scrolling the page, the cursor would hop to the nearest item on the current page. The control might scroll gradually or it could page a whole display. If flicked with the stylus or finger, as opposed to dragged, the scrolling could keep on moving until stopped with another touch, which would be good when you have a long way to scroll.
The other thought was a UI where the focused item would be a consistent position on the screen, possibly middle, or top centre, and the controls would move the items.
I like the idea of a rotating circle of items, that you mentioned. Might be nice with concentric circles or a spiral. In this case scrolling, would be rotation of course. Makes me think of the Ring Commands menu system in Secret of Mana.
One thought I had today, instead of a separate sidebar of tabs, these could be incorporated into the icon/item hierarchy. So at the top level would be the various sections, equivalent of the tabs, so more minimalist visually. There would be an 'up to parent' item (with a key shortcut), within the sub areas to get back up, or better this is the one button always on screen, like Magma's back button. There could be deeper levels if this suited uses i.e. file browsing. I'm thinking game button B to go into stuff/run and A to go up in the hierarchy, with X and Y for scrolling through. When scrolling the page, the cursor would hop to the nearest item on the current page. The control might scroll gradually or it could page a whole display. If flicked with the stylus or finger, as opposed to dragged, the scrolling could keep on moving until stopped with another touch, which would be good when you have a long way to scroll.
I do have a comment regarding this description which is also applicable to other things in general.
Keep in mind that this mainly is a description of how to display a hierarchy - not less, but also not more. Now, I would like to state clearly that it is not my intention to say that the idea is bad. Actually, the idea itself is a good (a complicated, if you think about it!) one. The problem lies in the fact that you have to find out _in_which_contexts_ it is a good idea, since information is missing. My intention is to explain that any idea (not only this one, and not only any of those related to user interfaces) /may/ sound good only because details are missing which might, or might not, have killed it - you can't tell without having them. It is only after evaluating and contemplating about at least the most obvious "details" that it's possible to say whether the idea could work or has to be improved (which, in my humble opinion, should in any case never be a reason to stop trying - after all, many of the best things that we have today started with a rather unspecific idea that often seemed to be useless to others).
Maybe this helps: Think about if this interface gives the user what she really wants. What benefits would the user have? Try to imagine users of various tech-savvyness using this for specific use-cases, and questions will probably start to arise.
As you hopefully can see now, details are at least roughly as important as much as they are interdependent on each other's properties in a specific idea. For things such as graphical user interfaces, where many things are connected to many other things, much thinking is required to catch a glimpse of whether an idea /might/ turn out to be good, and even if you believe that you're sure about something, you might one day experience something that you did not expect at strawberries.
It's fun!
As a conclusion (and this is the actual judgement), while I do see and like the general idea that it incorporates, it is impossible for me to say whether I do or do not like the interface as it is currently described above without adding a lot to it (which would require a lot of time, probably change the interface and also invalidize my initial judgement). For that reason, I cannot and do not like the interface description as it is right now, but still encourage those who want to take the time to work on it to experiment with it nevertheless.
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.
Whenever a category view is being opened by the user, beautyget should first download screenshots 0, 1, 2 and 3 ("category-view-showfloor-initial") of games 0 to 8 (one after the other in order of appearance in list) to measure the average download speed and [...]
But the meaning of that changes as you look at the exact definition of "category-view-showfloor-initial":
Christoph.Krn said:
Screenshots 0, 1, 2, 3 and 4 will be compressed into one file ("category-view-showfloor-initial"), with subsequent screnshots being compressed in chunks of four (or less, if there are less left) [...]
In other words, the small preview pictures you can see at http://www.gp32x.de/board/index.php?/topic/50747-appstore-look/page__view__findpost__p__793248 would be scaled down by the server and merged into chunks of four. The actual preview pictures (accessible by tapping any of the small preview pictures or opening the detailed view) would be preloaded only after either no more small preview pictures would have to be loaded (i.e. all small preview pictures of the PNDs that are currently visible are already loaded, and the user is not scrolling the list) or the user tapped a small preview picture (whichever came first).
By using chunks of combined small preview pictures, the amount of data that would have to be transfered would be minimized(-ish). Therefore, a persistent local cache /might/ not be necessary. However, since to my knowledge some people experience slow network connections with their Pandoras, using a persistent cache and keeping its size sane might be the most viable option for creating a really good user experience. Keep in mind that more often than not, you will have an SD card available that you could put the persistent cache onto ("/media/<SDCARD>/pandora/cache" should be a standard for all files that are safe to delete, in my humble opinion) since PND managers are used for managing a comparatively huge amount of local data anyway. You could probably put in a ratio that prevented the cache from becoming too large in comparison to the combined size of all managed local PND files. The local software would then ALWAYS display the small preview pictures from cache first and only AFTERWARDS check for new versions of the small preview pictures and update them (both in the cache and the UI).
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.
Yes, you are right, it can be confusing. This is the main reason for why I am not yet perfectly satisfied with filter buttons either. However, they work quite well work for both advanced as well as average users, and they do have some nice advantages:
They do not have the main problem of menu-based solutions, which is that items can only be in one sub-menu even though they would also make sense in some other sub-menu.
The main problem of tag-based menus, which is clutter and thereby confusion induced by either tag-clouds or, funnily, the fact that items may appear in several sub-menus and not just one, are mitigated by the facts that there are custom filter buttons and no sub-menus, respectively.
Which is why I think they can be helpful. So here is an upgraded suggestion with ideas to un-clutter the buttons, hopefully it is helpful. It is a small improvement, therefore I am still not fully satisfied with it either. I do have an idea on how to /really/ improve this, but I have not thought it through yet. The next time I am waiting for something, I will probably use the time for doing so. It will probably be compatible to the following upgraded suggestion, but I cannot be sure about that.
You could color-code the buttons. In other words, you could e.g. make all filter buttons that indicate a status red, all buttons that indicate an actual category green and all "advanced" filter buttons ("[...] for example -replace all the *Game categories with a single "Game" one.") blue. You would have to update button statuses on the fly, so activating the blue "Games" button would also activate all respective green category buttons, disabling one of these green buttons would then disable the blue Game button (because only a subset of it would be activated) but not the other green ones, and so on.
Furthermore, you could put a hint into the user interface so the user understood that as long as she held the L and/or R button, the grid that contains the filter buttons would be visible as if she had just pressed the button that is currently labeled "All" in your current main UI (for instance, by putting a tiny pictogram of the L or R button in front of the label "All" - in the visual representations inside the spoiler below, this is indicated by a letter between two pipes; E.g. "|L|" for a pictogram of the left shoulder button). This way, you could make switching between the three main use-cases fast and easy for both touchscreen as well as physical button use (if you also put in a "Disable all" button; labeled "All" in the visual representations inside the spoiler below). These colored buttons would probably be unconfusing even though the status buttons would be integrated with the other "That one, please!" elements.
Default view of the filter button grid, opened by tapping the button "||L|, |R|: Filter buttons" (labeled "All" in the current UI) in the main UI:
Code:
------------------------------------------------------------------------
----------------- ----------------- ----------------- -----------------
| All | | Installed | | Not installed | | Upgradeable |
----------------- ----------------- ----------------- -----------------
----------------- ----------------- ----------------- -----------------
| Games | | Multimedia | | Work | | etc |
----------------- ----------------- ----------------- -----------------
----------------------------------- ----------------- -----------------
| etc very long name | | etc | | etc |
----------------------------------- ----------------- -----------------
----------------- ----------------- ----------------- -----------------
| category | | category | | category | | category |
----------------- ----------------- ----------------- -----------------
----------------- ----------------- ----------------- -----------------
| category | | category | | category | | category |
----------------- ----------------- ----------------- -----------------
----------------- ----------------- ----------------- -----------------
| category | | category | | category | | category |
------------------------------------------------------------------------
|DPAD| Select |B| Toggle ||Y| Edit | |X|, |L|, |R|: Close
------------------------------------------------------------------------
/\
|--- Explanatory bar that explains physical button usage.
"|Y| Edit |" is an "actual" button that can also be
tapped on the touchscreen.
This is the bar that is on top in the main UI, it
slides down like a drawer that contains the filter
button grid.
-List is scrollable
-D-Pad moves focus
-Button "All":
Black; Disables all other buttons; Does not filter (thereby showing
all PNDs, installed and not installed).
-Buttons "Installed", "Not installed", "Upgradeable":
Red; Selecting one disables all other red buttons.
-Buttons "Games", Multimedia", "Work", "etc" ("advanced" filter
buttons):
Blue.
-Buttons "category" (actual categories):
Green.
-If the filter button grid was opened by holding L or R, make
"|X|, |L|, |R|: Close" -> "|L|(LET GO): Close" or "|R|(LET GO): Close".
-If the filter button grid is opened through holding L, if the user
presses R, then keep the grid open even if she lets go of any or both
of these two buttons, and make
"|L|(LET GO): Close" -> "|X|, |L|, |R|: Close"
(and vice versa for opening via holding R; It is a good thing that this
is a "hidden" feature).
-Buttons can be rearranged via drag-and-drop or via holding the physical
game button "A", which "lifts" the currently highlighted button off the
grid as long as the user holds it down, so it can be shuffled around
using the D-Pad (It is a good thing that this is a "hidden" feature).
If the user presses the physical game button "Y" (for Edit), the configuration dialog for the currently highlighted button pops up. However, if the user taps the button "||Y| Edit |" on the touchscreen instead of pressing the physical game button "Y", gear icons pop up at the end of each button. Tapping a button then opens up the edit dialog for the button that has been tapped. The content of the explanatory bar changes.
Code:
------------------------------------------------------------------------
----------------- ----------------- ----------------- -----------------
| All |o| | Installed |o| |Not installed|o| | Upgradeable|o|
----------------- ----------------- ----------------- -----------------
----------------- ----------------- ----------------- -----------------
| Games |o| | Multimedia |o| | Work |o| | etc |o|
----------------- ----------------- ----------------- -----------------
----------------------------------- ----------------- -----------------
| etc very long name |o| | etc |o| | etc |o|
----------------------------------- ----------------- -----------------
----------------- ----------------- ----------------- -----------------
| category |o| | category |o| | category |o| | category |o|
----------------- ----------------- ----------------- -----------------
----------------- ----------------- ----------------- -----------------
| category |o| | category |o| | category |o| | category |o|
----------------- ----------------- ----------------- -----------------
----------------- ----------------- ----------------- -----------------
| category |o| | category |o| | category |o| | category |o|
------------------------------------------------------------------------
||X| Done |
------------------------------------------------------------------------
-"|o|" at the end of a button indicates the location of the gear icon.
- The physical game button "X" now goes back to non-touchscreen-edit
mode instead of closing the filter button grid altogether.
At the end of the list:
Code:
------------------------------------------------------------------------
| category | | category | | category | | category |
----------------- ----------------- ----------------- -----------------
----------------- ----------------- ----------------- -----------------
| category | | category | | category | | category |
----------------- ----------------- ----------------- -----------------
----------------- ----------------- ----------------- -----------------
| category | | category | | category | | category |
----------------- ----------------- ----------------- -----------------
----------------- ----------------- ----------------- -----------------
| category | | category | | category | | category |
----------------- ----------------- ----------------- -----------------
----------------- ----------------- ----------------- -----------------
| category | | category | | category | | category |
----------------- ----------------- ----------------- -----------------
----------------- ----------------- ----------------- -----------------
| category | | category | | category | | category |
----------------- ----------------- ----------------- -----------------
-----
| + | <- "Add" button adds an empty blue button and opens it in
----- configuration dialog; Color: gray background, green "+".
------------------------------------------------------------------------
|DPAD| Select |B| Toggle ||Y| Edit | |X|, |L|, |R|: Close
------------------------------------------------------------------------
-Buttons can be deleted in their respective
configuration dialogs (opened via "||Y| Edit |").
-"+" button at end of list instead of in "Edit" mode avoids conflicts
between usage of physical buttons and touchscreen use in dedicated
touchscreen-edit mode; Also removes the need for a dedicated "Edit"
mode unless using the touchscreen, which is a good thing. When "+"
button is pressed, the configuration dialog for the currently
highlighted button pops up, with a configuration already inside which
includes all filters from the buttons that are currently activated.
I have some more things that would further speed up using this interface, but I'll stop annoying you with them for now. Also, the effort needed for a correct and understandable explanation of these details would probably exceed the effort required for an actual implementation.
Most of the average-user-y people I know that have an iPhone constantly have a large number of "app" updates waiting to be installed. They do not even review these updates, they simply install it and would like to avoid the hassle of having to wait for anything to finish. In related news, one of the most interesting aspects of creating software for the Pandora is that there is a very wide user base that includes many tech-savvy people, and also many users who do not even know what a shell is.
I think that a good way to solve this potential problem is to ask the user every time she installs a PND if it should be kept up-to-date automatically (of course, those PNDs for which she chooses yes should be revertible to any previous version). I have not really thought this through yet, but a dialog that asks the user upon activating the "Install" button of a PND if that PND should be kept up-to-date automatically would probably be a good thought to start with.
So much for my much too extensive thought processes on the topic. I hope they are of any use. DISCLAIMER: This post may contain traces of nuts, make you go nuts or be nuts so important after all. Keep in mind that I am not a user interface expert either.
One thought I had today, instead of a separate sidebar of tabs, these could be incorporated into the icon/item hierarchy. So at the top level would be the various sections, equivalent of the tabs, so more minimalist visually. There would be an 'up to parent' item (with a key shortcut), within the sub areas to get back up, or better this is the one button always on screen, like Magma's back button. There could be deeper levels if this suited uses i.e. file browsing. I'm thinking game button B to go into stuff/run and A to go up in the hierarchy, with X and Y for scrolling through. When scrolling the page, the cursor would hop to the nearest item on the current page. The control might scroll gradually or it could page a whole display. If flicked with the stylus or finger, as opposed to dragged, the scrolling could keep on moving until stopped with another touch, which would be good when you have a long way to scroll.
I do have a comment regarding this description which is also applicable to other things in general.
Keep in mind that this mainly is a description of how to display a hierarchy - not less, but also not more. Now, I would like to state clearly that it is not my intention to say that the idea is bad. Actually, the idea itself is a good (a complicated, if you think about it!) one. The problem lies in the fact that you have to find out _in_which_contexts_ it is a good idea, since information is missing. My intention is to explain that any idea (not only this one, and not only any of those related to user interfaces) /may/ sound good only because details are missing which might, or might not, have killed it - you can't tell without having them. It is only after evaluating and contemplating about at least the most obvious "details" that it's possible to say whether the idea could work or has to be improved (which, in my humble opinion, should in any case never be a reason to stop trying - after all, many of the best things that we have today started with a rather unspecific idea that often seemed to be useless to others).
erm... I could be mistaken but I thought the point of this discussion was just to get the ideas out there. Once we have a lot of ideas to play with *then* we can look at what does or does not make sense in what context.
erm... I could be mistaken but I thought the point of this discussion was just to get the ideas out there. Once we have a lot of ideas to play with *then* we can look at what does or does not make sense in what context.
I fully agree that ideas should be judged upon only after collecting (nearly) all of them, since that only makes sense when the context is clear. Note that I applied negative judgement to the description (more precisely: its vagueness, which could easily lead to problems here and cause people to not "see" things), not the idea itself that it is based on. What I tried to say wasn't "No it shouldn't be used. I don't like it because you didn't think it through.", but rather "I don't like it because it's impossible to say if I would like it, which is why we (someone, but not me (at least currently) for lack of time) shouldn't use but instead work with it."
If I understood you right, then what you just said is implied in what I said, just that that was not the point of my explanation (which was to explain why details are important). It would be nice if you could provide me with further feedback so I can try to avoid future similar misunderstanding. (Or maybe I just did not understand what you just wrote.)
Christoph.Krn: Wow. That was one long post . I read it once, but will need to read it again when I'm more... awake (08:33 here).
(slightly off-topic)
Regarding the preview loading, I agree it would probably be possible to achieve the UI you describe by sending only thumbnails first and doing smart preloading in the background. It would only hold up to a limit though. If the user is breezing through the apps it could lag behind, but that's a pathological scenario. Anyway, that system requires quite a lot of support from the server and as such is not readily implementable here (which you never actually suggested, just making this clear), but I see the perks.
Regarding the status filter buttons: I simplified the UI to "Browse" and "Installed" modes. In "Browse" you find and install new applications, and in "Installed" you can upgrade or remove individual packages. In the "Installed" view the packages with upgrades float to the top of the list. An "upgrade all" button is always visible next to the sync button, and only enabled when there are updates available for installed software.
(/slightly off-topic)
The automatic updates sound like a good idea, but there are a lot of pitfalls to keep in mind. Because the user is potentially not aware of the updates happening, she may not take the necessary precautions, such as making sure the battery lasts or that the device doesn't drop out of wlan or go to low power mode. Furthermore, some might find it irritating to find their network connection lagging during a multiplayer game because the latest update of Battle for Wesnoth (a random large pnd that popped into my mind) is downloading in the background. In my opinion full automation is a double-edged sword, and requires a lot of close and tender care to get right
Regarding the preview loading, I agree it would probably be possible to achieve the UI you describe by sending only thumbnails first and doing smart preloading in the background. It would only hold up to a limit though. If the user is breezing through the apps it could lag behind, but that's a pathological scenario.
I imagine an image download manager that would pause downloading of any images that had moved off screen, until onscreen images were complete, would help. In some cases lag in image loading is inevitable, but preferable to "Loading please wait" before using the app. An idea for the image loader, using progressive JPEG, it could download only as many passes needed for the current display scaling level, and more later where required. For a screenful of images, it could load the first pass of all images first and so on.
Regarding image cache, its fine for now, as Panorama's appdata is already on SD, but when it moves to the nand, the image cache would need to be disabled I think. A cache location on SD could be specified in configuration.
Solution to inconvenient auto updates: Simple: Updates on/off switch, in system tray. Advanced: Update checking frequency (every hour, 2 hours etc), scheduled time(s) of day, or suspend (don't update for 1 hour, 2 hours etc).
If I understood you right, then what you just said is implied in what I said, just that that was not the point of my explanation (which was to explain why details are important). It would be nice if you could provide me with further feedback so I can try to avoid future similar misunderstanding. (Or maybe I just did not understand what you just wrote.)
Yes "the devil is in the details" they say. However, details depend on the fundamental decisions. One analogy I give to my clients is, in building a house, you can't decorate the rooms before you lay the foundations, but you can be thinking about it. I like to do the bulk of analysis in my head, as it's faster, requiring imagination and visualisation in evaluating and combining both generic and specific ideas. It takes too long to test every idea practically. I like to think outside the box first and then apply it to use cases and see what sticks, then try some real tests. Please think through our ideas and flag up potential problems. We can then consider solutions or if unworkable, just reject the ideas. Thanks
Next random idea: Considering the environment interacts with C++, I suspect it's possible to manipulate the images, text etc for 3D effect, render them to an image and display that. I then thought of Mac O/S finder when flipping through images:
However, details depend on the fundamental decisions. One analogy I give to my clients is, in building a house, you can't decorate the rooms before you lay the foundations, but you can be thinking about it.
Yes, but what do you declare as "details"? For a subset of customers (and that's the essence of what usability is about), (most of) the furniture and its positioning may decide where to put (some of) the walls, with everything "below" that being "details". In that case, if YOU were thinking that furniture was "details", then it would not hurt if you adopted your idea of "details". But you would not have known if the customer hadn't told you, and this is one of the very few situations where customers are able to do this nearly accurately enough.
In another deliberately exaggerated scenario, a customer might believe that everything that is walls and "below" was "details" just the way you believed for the previous customer that furniture was "details". In that case, you would have to explain to the customer that it's not a good idea to lay any foundations before knowing what the walls should be like.
This is the abstract idea that I called "context".
...it ends where you and your customer are getting into fights about what are details (or the details themselves), and nothing gets done. At the end, there's always someone who has to decide.
In other words, what I'm trying to say is "You do not know what you do not know." in a more explanatory way of saying "Thinking to think outside the box is not thinking outside the box". By definition, very uncommon ways of thinking are required to think outside the box - otherwise, progress is either rather incremental, or non-existent because of too simple copying of what others already did when they thought outside the box.
In other other words, do not think about the details because "The devil is in the details.", think about what exactly you see as details in order to think outside the box and to see what others didn't.
-----
I think the part of my post that you quoted may have unintentionally sounded too negatively, because...
I like to do the bulk of analysis in my head, as it's faster, requiring imagination and visualisation in evaluating and combining both generic and specific ideas. It takes too long to test every idea practically.
(...)
We can then consider solutions or if unworkable, just reject the ideas.
...I agree with this (except that I am not the only one to judge about these ideas - everyone should). Therefore, I would also like to encourage everyone who reads this thread to post any and all related ideas, no matter how silly, unimportant or useless they may sound. This has proven to be useful countless times before. Anyone of us can only really judge about them after we can see them in relation to other related ideas, not any earlier (unless "nothing gets done").
I imagine an image download manager that would pause downloading of any images that had moved off screen, until onscreen images were complete, would help. In some cases lag in image loading is inevitable, but preferable to "Loading please wait" before using the app. An idea for the image loader, using progressive JPEG, it could download only as many passes needed for the current display scaling level, and more later where required. For a screenful of images, it could load the first pass of all images first and so on.
Regarding image cache, its fine for now, as Panorama's appdata is already on SD, but when it moves to the nand, the image cache would need to be disabled I think. A cache location on SD could be specified in configuration.
This was more toward his beauty-get idea, but it's relevant here too (albeit a bit on the technical side). Panorama currently as far as I know works like this. The image loading routines are inside Qt, but it seems to at least stop downloading stuff that goes offscreen. Using JPEGs has its pros and cons. In general JPEG isn't that good at displaying "generated" stuff (as opposed to photographed), so while we'd get faster initial loading times we'd probably lose in the final quality. Also converting all previews/icons to JPEG serverside (since PND allows other formats) sounds like a lot of work there.
Anyway, Let's try to keep focused on the UI, and not the inner workings
Solution to inconvenient auto updates: Simple: Updates on/off switch, in system tray. Advanced: Update checking frequency (every hour, 2 hours etc), scheduled time(s) of day, or suspend (don't update for 1 hour, 2 hours etc).
Yes, that solves the "updates in the middle of my multiplayer game" problem, if the user bothers to always change the update mode. Doesn't help with the draining battery or inadvertant low power mode or losing wlan, unless the user babysits the updater to tell it when it's safe to update, at which point he could just press the "update all" button. All those things you mentioned are good customization options to an automatic updater, but they don't make it smarter, so it knows when to do stuff. For example a smart updater would monitor the system's network traffic and determine if there's enough free bandwidth (using the term broadly (pun not intended)) so that the updating won't be in the users way, if there's enough battery so it won't run out, low enough cpu usage so the user's game won't stop jumping, some time since the last activity so the user might not immediately shut down the machine, no major jumps in wlan signal strength so it won't probably run out and so on. All this however is a lot of work
Well... Cloudef's milkyhelper/notify are all well and good if you use a thing with a system tray . I'm going for a more integrated solution here. Think less like XFCE, more like minimenu in terms of control.
Next random idea: Considering the environment interacts with C++, I suspect it's possible to manipulate the images, text etc for 3D effect, render them to an image and display that. I then thought of Mac O/S finder when flipping through images:
Like you said, it depends on the context. Details can change, depending on usage. The fundamental design should be made to faciliate a wide range of possible details, ideally any that we could ever desire.
In other other words, do not think about the details because "The devil is in the details.", think about what exactly you see as details in order to think outside the box and to see what other's didn't.
Very interesting statement, I don't fully grasp the implications of what you said here, so I'll think about that some more.
Thoughts of: "Do not try and bend the spoon. That's impossible. Instead... only try to realize the truth. There is no spoon. Then you'll see, that it is not the spoon that bends, it is only yourself. "
I think we are generally thinking alike although perhaps talking at cross purposes, feel free to explain further if/where you think I'm wrong, I might learn something.
Additional: Christoph, I've re-read your posts and I'm seeing more clearly what you are saying to me. Thank-you!
Interlaced PNGs can have progressive loading. I disagree that image conversion server-side is much work, were it needed, a one-off batch run for existing ones, then create them on uploading. GD or ImageMagick does all the work. I thought image loading had some minor relevance, even at this stage, because it affects availability of images for display, and how slick the UI will be, and might affect some design decisions of what is going to work in practice.
For example a smart updater would monitor the system's network traffic and determine if there's enough free bandwidth (using the term broadly (pun not intended)) so that the updating won't be in the users way, if there's enough battery so it won't run out, low enough cpu usage so the user's game won't stop jumping, some time since the last activity so the user might not immediately shut down the machine, no major jumps in wlan signal strength so it won't probably run out and so on.
Well... Cloudef's milkyhelper/notify are all well and good if you use a thing with a system tray . I'm going for a more integrated solution here. Think less like XFCE, more like minimenu in terms of control.
Thinking modularly, I imagine the Panorama UI as the front end to some back end technology i.e. integrated with. Commonality is good if there are multiple front ends (which there already are), otherwise we could be storing and updating multiple copies of the repo in different places (and formats).
Next random idea: Considering the environment interacts with C++, I suspect it's possible to manipulate the images, text etc for 3D effect, render them to an image and display that. I then thought of Mac O/S finder when flipping through images
Interlaced PNGs can have progressive loading. I disagree that image conversion server-side is much work, were it needed, a one-off batch run for existing ones, then create them on uploading. GD or ImageMagick does all the work. I thought image loading had some minor relevance, even at this stage, because it affects availability of images for display, and how slick the UI will be, and might affect some design decisions of what is going to work in practice.
Thinking modularly, I imagine the Panorama UI as the front end to some back end technology i.e. integrated with. Commonality is good if there are multiple front ends (which there already are), otherwise we could be storing and updating multiple copies of the repo in different places (and formats).
Panorama at it's core is a context for showing QML documents. It utilizes QML plugins to provide the more advanced features, such as settings management, application information and launching, package management and system information. These plugins are one common part between the interfaces, though not every interface have to use them all. Less plugins means faster loading and all that. The interfaces can also share customizable components in the form of component QML files. For example here I've implemented a button component that could be used in other UIs. Similarly it would be possible to make, say a WLAN indicator component, which would only have to be updated once to benefit all the UIs that use it.
This one is quite easy as well. I will most definitely be able to do this if it is wanted
I try to keep a small distance to the suggestions here as to not accidentally dictate what the UI is going to be like. After all, I'm doing this one for all of you, going by what you want.
Here's how I come up with ideas for UIs that work differently:
The most important question is: what kind of UI would you want to use? After all a UI is basically an interface between you and the stuff you want to do on your pandora (ok, the input devices are also between you and the UI, but this is a good starting point). So the kind of interface you'd want is the kind that best supports what you do with it. Of course it's always nice if it also happens to be pretty . Think of all the things you regularly do with your pandora and break them down to use-cases. For example: "starting an application I know by name" (like a specific game), "starting an application I know by description" (it's the NES emulator, what was its name), "installing a specific package", "browsing to find something new to do", "checking what time it is", and so on. After these are clear, it's possible to rank these by how often you do them, eg. which would benefit the most for being easy to do. Then you can optimize doing those things so the most common stuff is the easiest to do. Design a UI that makes them intuitive and effortless. Then take the next thing on the list and think how you could integrate it into your UI. Rinse and repeat. I don't do this in a strict or formal way, mostly roll things around in my head, but it's worked out so far
Would it be possible to create plugins for emulators, that present your roms in a way that picklelauncher does it?
Think of a kind of frontend like hyperspin. That could mount the pnd on demand and supply the emulatorexecutable with options and rompath.
So somebody would have to code a plugin, that has an ui for the specific emulator including configoptions and romselection and maybe some nice pictures
Yes. To be specific, you could store the number of times the applications have been launched in Setting, like "Magma" UI stores favorites. It would be quite easy to accomplish this. The cloud itself wouldn't be too hard either, depending on how nice you'd like it to look
Would it be possible to create plugins for emulators, that present your roms in a way that picklelauncher does it?
Think of a kind of frontend like hyperspin. That could mount the pnd on demand and supply the emulatorexecutable with options and rompath.
So somebody would have to code a plugin, that has an ui for the specific emulator including configoptions and romselection and maybe some nice pictures
Yes. It would be possible. If I was implementing something like that, I'd probably first make a configurable ROM data model/launcher as a QML plugin to provide data for the frontend. Then create the frontend as a QML component that can be included in UIs. Lastly I'd use the TextFile plugin to configure the frontends (theming, configurable settings etc.) and Panorama's Settings system to store system-specific settings to panorama.conf.
I still believe that we should develop a protocol for inter-process communication between emulators and external menus.
Whenever an emulator switches to the menu (and its IPC protocol option is enabled) it would start listening for RPC's through which an external menu such as Panorama or XBMC (1) can control all emulators in a uniform fashion.
Though I do not expect all emulators to support such a protocol out of the box, if we have a version up and running, it will provide an incentive to implement it in other emulators as well. Perhaps some libraries can be made to aid devs in adding this to their application.
(@1) I have an XBMC based GUI replacement project which I still haven't posted about.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.
