Release PND management suite

[porg]

Honestly, I'm confused, and don't know what should be discussed where now.


Please move the posts accordingly, and tell me where I shall carry on.

 

[bzar]

porg: if you have a concrete feature request like "add support for reverting backed up PNDs" or a bug report like "last updated PND list does not update on sync", put them to the other thread. Basically things put there should be presentable with a single bullet point on the list, so I can just update the list without reading walls of (albeit interesting and relevant) text.


General conversation that could lead to such feature requests here. Feature requests can point here for further explanation if necessary.

 

[bzar]

I'm working on a performance-enhancement update for PNDManager, and I'd like to ask for opinions here.


First some technical background:


The main thing making list scrolling and loading slow is a complicated delegate. A delegate specifies how a single item on the list is displayed. For example in categoryview the delegate is quite simple, consisting of the title text, icon and a multi-row text field for additional information. Search item delegate is more complex with installed icons, rating and a formatted list of categories, which is why it scrolls slower. Another important factor is the size of the delegate and how many are displayed at a time. This is why home screen lists scroll quite nicely: small, simple delegates with a maximum of six showing at any time.


I was thinking about how to make the main listings more performant and thus more finger friendly at the same time. This led me to thinking about making the category/search listings single-column, with some information about the selected item displayed on the other side. This way I could make the delegates really simple (basically icon + title) with only half of the current amount of items showing at once.


Now, there is of course the tradeoff of less information showing on the screen at once, but on the other hand I could display more information about the selected package. Also the general feel of the interface would be smoother because of less jerkiness and faster view loading.


For installed view, I was thinking about using this second column to show progess bars and stuff (with a simple percentage shown on the delegate).


It's not a win/win situation, so I'd like some input on whether this would be a welcome tradeoff before continuing.

 

[Binky]

I'd guess that the benefits of smooth, comfortable scrolling would outweigh the reduced amount of information per screen-full

 

[fusion_power]

I guess HW-Acceleration should solve all the speed problems. I've seen how fast and fluid an typical iOS GUI can be, on my buddys IPod Touch. And this thing is not faster than our Pandora, so I guess it IS possible...of course I have no clue how exactly it has to be done...


However, the PND Manager GUI already works very nice.

 

[porg]

For perceptional reasons I recommend to only show 1 item per row ("delegate") anyhow. If that improves performance, even better!


Multiple items per row only work fine for perception if they have 1 or at most 2 attributes (such as MiniMenu's or a file browser's Icon+Title view).


Otherwise the second column always gets less attention (you typically read the first column from top to bottom, then jump to the next column, go from top to bottom, etc, because the alignment is an orientation guideline to the eye, whereas jumping left, right, left, right all the time takes much more adaption time to skip from one to the next item. (Even if one uses multiple columns, then the sorting should be first column top to bottom, next column top to bottom, and so on. Putting the cursor over the bottom boundary, must thus update the whole screen, starting again on the left column top to bottom, next column, and so on)


As a visual example: PanoramaMilky solved the

https://www.youtube.com/embed/48Ep1hpyL8c?feature=oembed For PNDManager I have some more attributes in mind for certain screens (size, version, category, maintainer, etc). I will sketch some wireframes somewhen later, and show them here.

 

[bzar]

I guess HW-Acceleration should solve all the speed problems. I've seen how fast and fluid an typical iOS GUI can be, on my buddys IPod Touch. And this thing is not faster than our Pandora, so I guess it IS possible...of course I have no clue how exactly it has to be done...


However, the PND Manager GUI already works very nice.

That kind of HW acceleration requires quite a deep level of integration and optimization. Current Qt is not built for that (the focus is on cross-platform use), but the next one (Qt5) should be. When I have a little time from PNDManager I intend to attempt porting Qt5 alpha to pandora. If it works as well as my current mental picture of it implies, I'll start porting panorama to it immediately. It's still not magic though .


Regarding the simpler delegates, I could whip up a prototype and post a screenshot here.

 

[bzar]

And here's the prototype. It's a LOT faster scrolling and actually shows more information. The entire left side (between the top- and bottom bars) is scrollable so the packages actually have a healthy amount of space. tapping on a title on the left selects it and tapping a selected title has the same effect as the show button (moves to package view).


Before anyone suggests adding more stuff to the list items (in the scrollable area), I'd advise against it. even a bit more complex delegate is no longer smooth

 

[Binky]

The big 'show' button seems a bit of a waste - Could it fetch the stars rating from the repo and display them somewhere in that side panel?

 

[bzar]

The show button is finger-friendly. It doesn't look as huge on pandora's screen.


Forgot about the rating, adding now


EDIT: to give some sense of proportion, the show button is actually just about the size of my finger tip (~7mm) in height.

 

[Binky]

The show button is finger-friendly. It doesn't look as huge on pandora's screen.


Forgot about the rating, adding now


EDIT: to give some sense of proportion, the show button is actually just about the size of my finger tip (~7mm) in height.

Fair enough, its more like 15mm on my screen :rolleyes:

 

[bzar]

New release possibly today. Last tunings taking place now.

 

[bzar]

Uploading version 1.1.0.0 to repo now. I thought a new minor version is in order to commemorate the new installed view


EDIT: And it's there. Have fun

 

[fusion_power]

Very nice Work, it is indeed faster, for example when scrolling through the preview images.


On the section in the above screen, there seems to be a touchscreen bug, you can't push the sorting option buttons, at least not in my case (I'm still at hotfix 6 if this counts).


I also would suggest that these buttons are always visible, at the moment you scroll them away when going down the list. ^^

 

[Binky]

I also would suggest that these buttons are always visible, at the moment you scroll them away when going down the list. ^^

What about always providing an indicator and the ability to change them with buttons, but not finger-friendly buttons - could the black bar at the top be used more?

 

[bzar]

The sorting buttons are on the scrollable area by design in both category view and installed view. The rationale is that there really isn't a use case for switching sorting elsewhere than at the top of the list that I can think of. When you're testing the features, sure, but that's only once or twice. On the other hand this way the actual content (the list items) have way more space to use instead of a cramped corner.


An indicator might be feasible, but I'm not sure where to put it. Maybe some small icons at the top of the list element when the sorting buttons are not visible? The title bar would be a bit funny place IMO since it has no spatial or conceptual connection to the list itself, but the entire view. The bottom bar on the other hand is reserved for globally relevat functions.


In any case, before I start doing modifications on that I'd like to find a use case that actually needs (or benefits from) either always visible sorting buttons or indicators.

 

[Christoph.Krn]

I currently don't have much time, but given that a side-panel is quite intrusive to the PNDManager interface, here are some rather isolated observations and considerations.


The attached images are rather dirty; for instance the guihint for "Upgrade all" is wrong, and the description does not fit the selected PND.


--


By pressing F1, a PNDManager user currently has the choice between one of two modes, "More usable controls" or "Better overview", which is not exactly elegant the way it is. I suggest to instead either use no guihints at all, or to permanently show them and improve the way guihints are integrated into the interface. Considerations:

• What I assume to be the biggest problem about guihints integration in PNDManager: PNDManager has 4 global categories, represented by 4 icons in the bottom bar. 4 is the maximum number of objects a human being is capable of immediately knowing the count of (See: Subitizing), any more objects likely cause the user's brain to require significantly more time when looking at them (as long as it's not used to them, at least). Thus, adding shoulder-l and shoulder-r guihints next to the category icons is very likely to significantly reduce overview. Significantly reducing the size of these hints or making them more transparent is unlikely to solve the dilemma. Try to integrate these two guihints in a different manner.
  
• Integrating guihints into buttons in a different manner can reduce clutter, see attachments for examples.
  

--


Further considerations:

• Experimenting with giving all buttons related to filtering sharp corners to indicate that they are serving a purpose specific to filtering; guihints can be used to indicate that these buttons are buttons despite not having round corners (See: Affordances).
  
• Experimenting with adding a "sorted" indicator to the top bar when current sorting differs from default sorting so that the list's status is clear at all times.
  
• Experimenting with making the side-panel's background color !=#FFF (or possibly even adding texture).
  
• The side-panel's contents have to be chosen extremely carefully at all times. It cannot absorb a lot of information, and an attempt at forcing it to do so is likely to result in redundancy of concepts.
  

------------------------------------------------------------------------

Your level of conversation on this topic is high-end in the context of this community.

That's not relevant!


In the context of turtles, my sportiness is simply astonishing.


Usability is also about expanding the existing instead of blindly applying it, nonetheless I simply do not have certain usability-related knowledge.


-----

Isn't it the biggest advantage of an GUI over a command line, because it IS an GUI?

My point is that current graphical PND package managers do not offer a lot more than a command line does, despite having a GUI.


(Just for completeness: I think neither GUI nor CLI are superior to the other, as both are having unique benefits and drawbacks.)


------------------------------------------------------------------------

 

[bzar]

This is starting to become conversationy, and not a bug report nor a feature request. Could a mod move this and the post above to the rebirth thread?

I currently don't have much time, but given that a side-panel is quite intrusive to the PNDManager interface, here are some rather isolated observations and considerations.

The side panel as an idea was something useful to fill the other half of the screen. The scrollable list needed to be simpler because of performance issues. Any better ideas of what to put there are welcome.

The attached images are rather dirty; for instance the guihint for "Upgrade all" is wrong, and the description does not fit the selected PND.

It's wrong? How? Y upgrades all. The description is the selected PNDs description. I don't understand this one at all.

By pressing F1, a PNDManager user currently has the choice between one of two modes, "More usable controls" or "Better overview", which is not exactly elegant the way it is. I suggest to instead either use no guihints at all, or to permanently show them and improve the way guihints are integrated into the interface. Considerations:

• What I assume to be the biggest problem about guihints integration in PNDManager: PNDManager has 4 global categories, represented by 4 icons in the bottom bar. 4 is the maximum number of objects a human being is capable of immediately knowing the count of (See: Subitizing), any more objects likely cause the user's brain to require significantly more time when looking at them (as long as it's not used to them, at least). Thus, adding shoulder-l and shoulder-r guihints next to the category icons is very likely to significantly reduce overview. Significantly reducing the size of these hints or making them more transparent is unlikely to solve the dilemma. Try to integrate these two guihints in a different manner.
  
• Integrating guihints into buttons in a different manner can reduce clutter, see attachments for examples.
  

Think of it this way. First the user doesn't really know what button does what, so the hints are helpful. At some point he may want to turn them off from cluttering things, so he can. At some point however, he doesn't remember which button was the cancel key, so he quickly presses F1 to see the hints, then turns them off again. I know this is exactly how I would use it (though I do remember all the keys). Don't think of them as separate modes. Think of it more like the HUD of Zelda Skyward Sword, which too has optional control hints. And most people turn them off gradually as they start getting used to them.


I thought the number was seven, not four? I probably remember incorrectly. The hints are already so tiny and barely visible on a pandora screen I can't see how it would be more usable to make them indistinguishable.


The example upgrade all button looks awesome, but requires bitmap artistry which I suck at. Making all the buttons and controls look consistently that good would require a dedicated artist. I can barely make passable low resolution pixel art (see wars: commando). All graphics in PNDManager are either external bitmaps (iconic icon set and guihints) or stuff I can make directly with QML, which is... pretty much different rectangles and text .


On the other hand the buttons in your samples don't look very finger friendly. The most difficult thing in making PNDManager has been to get the UI work naturally with both game controls and touch screen, and you always have to consider both plus pandora's pixel size when designing controls. On pandora's screen a comfortably finger-pressable button is 64px high, a 32px button already requires precise aiming and anything below that is stylus land.


Also: why is the info bar in the left side? Isn't it more natural to select from left side, inspect on right side? The actual content of the screen is the package list, not the information sidebar so IMHO it should be on the left side which always has precendence in what order people percieve the UI.

Experimenting with giving all buttons related to filtering sharp corners to indicate that they are serving a purpose specific to filtering; guihints can be used to indicate that these buttons are buttons despite not having round corners (See: Affordances).

This could work, though I'm already differentiating them as option buttons by a completely different style from action buttons.

Experimenting with adding a "sorted" indicator to the top bar when current sorting differs from default sorting so that the list's status is clear at all times.

Possible, already proposed by Binky. I counterproposed floating indicators at the top of the list element when the sorting buttons are not visible. The title bar is a bit confusing place for such control-specific information.

Experimenting with making the side-panel's background color !=#FFF (or possibly even adding texture).

It's not #fff, it's #f8f8f8 to differentiate it from the list's background.

The side-panel's contents have to be chosen extremely carefully at all times. It cannot absorb a lot of information, and an attempt at forcing it to do so is likely to result in redundancy of concepts.

I absolutely agree. The current contents are stuff I thought would be helpful, but good ideas regarding this are welcome

 

[bzar]

WARNING!


Some applications when started from PNDManager apparently leak input to PNDManager for some reason! Trying to fix this asap, but meanwhile I do NOT recommend using the launching feature!

 

[bzar]

Fixed, update uploading (1.1.1.0).