260 replies to this topic

[BuGless]

it generates a huge amount of skin-error reports on openeing every single screen. Isn't this an extra load for E2? Anyway: it makes E2 feedback difficult to read.

I'll do something about those skin-errors in due course. Most likely I'll add an option to enigma and the skin to suppress them. The extra load is negligible.

But even this generic template doesn't show all labels: e.g. the green button in the about-screen has none.

If I missed one (like this one), please report. So far, this seems to be the only one missing.

2- You told me you're now working on a way that only those colour-buttons that actually apply to a specific screen will show up. Is that also going to work for the extra buttons several screens need (such as the buttons 'menu', 'info' and 'text')? I already noticed a 'ConditionalShowHide' for the textbutton: is that a first step in that direction?

It's an attempt. There is another rationale at work though:
Nearly every screen contains numerous active buttons. Most of these buttons are undocumented. The reason that we supply a legend for the four coloured ones usually stems from the fact that the coloured buttons are generic and are the designated "special-action" buttons. All the other buttons have (hidden) extra meanings which hopefully can be inferred from the actual text on the button (the coloured buttons lack that, obviously). So this raises the question: why single out some of the other buttons and provide an indicator they can be pressed *without* showing a legend what it means? I.e. it would be logical to either not document *any* other buttons besides the coloured ones, or one should document *all* other buttons, preferably with legends... And guess what, the latter option is already provided for by means of the help button.

So, in short, the only logical conclusion would seem to be that having those extra TEXT, INFO, MENU buttons on screens is of questionable value and merely clutters the screen needlessly in most cases.

3- Maybe it will also be possible to create a generic way to display the title? As it is now some screens need a hard 'title="XXXXX", while others generate (translatable) titles with the widget 'source="Title" render="Label" '

There already is a generic way. The generic title of a screen is displayed in the upper right. If a screen does it differently and doesn't show up the right way, the screen/plugin needs to be fixed, not the skin. Most screens get it right.

4- I take it that all commonly used functionality will get skinned screens? atm several (such as Device Manager and positioner setup) are not skinned.

Yes, the rule is, if a screen is seen often enough, it should be skinned. If a screen is extremely rare, skinning it in a generic skin is a waste of resources.
I don't see all the common screens on my device though. Sometimes I do not know how to open it, sometimes I lack the plugin for it. Either notify me of screens that are missing, or provide patches (the latter is preferred of course).

> 5- The length (heigth) of the widgets list/config etc is not correct: the length should be a multiple of the item height to be displayed properly. As I understand it fontsize will be configurable: will that take into account the itemheight and height of the widget ( I hope I expressed myself clear enough).

Yes, some list/config widgets have a separate Itemheight parameter which should be dependent on font sizes. The widgets need to be fixed to allow for this. It's on the todo list, but if someone fixes it for me, they're more than welcome ;-).

> 6- General remarks: the distribution over the available space doesn't seem to be optimal (yet).
> See e.g. the channel-list: the list is very small (might be widened a bit to the left), and the description area (under the PiG) is too wide: it almost touches the channels.

It's a tradeoff, of course. With regards to the channel list vs. description area... In most screens I started out with a screen partitioned in four equal tiles. If I were to make the channel list wider (yes, there is room), then the description area indeed gets smaller; it would allow less text to fit in there, is that good or bad? You're saying that the description area almost touches the channel list; does that mean that you'd like a larger gap there for better readability? Keep in mind that fonts could be a bit smaller in general, so a wider channel list might make the channel list needlessly wide, because the text rarely will touch the right side of the screen anymore.


> Also the top bar (with the title etc) is very small (low in height), while at the same time the colour-buttons are still far away from the bottom.

With regard to the top bar and the menu button bar, they're symmetrical in size. Meaning: if on your screen it looks asymmetrical, then most likely your TV-display is not centered vertically; is that possible?

Edited by BuGless, 13 February 2013 - 09:29.

[Rob van der Does]

So, in short, the only logical conclusion would seem to be that having those extra TEXT, INFO, MENU buttons on screens is of questionable value and merely clutters the screen needlessly in most cases.

That's one way of looking at it. IMHO there are plenty of screens where it is not obvious that not shown buttons provide extra functionality/information.

There already is a generic way. The generic title of a screen is displayed in the upper right. If a screen does it differently and doesn't show up the right way, the screen/plugin needs to be fixed, not the skin. Most screens get it right.

But as it is now you use one of the two options ('title="XXXXX" or the widget 'source="Title" render="Label" '), depending on the specific screen.
Given the fact that you made the colour buttons generic, I would have expected the same here.

You're saying that the description area almost touches the channel list; does that mean that you'd like a larger gap there for better readability?

I sure would. The present 'lack of gap' makes it hard to read.
I know: there's never enough space, so choices will always be a compromise. And in the end the skinner decides what he deems best.

With regard to the top bar and the menu button bar, they're symmetrical in size. Meaning: if on your screen it looks asymmetrical, then most likely your TV-display is not centred vertically; is that possible?

LOL, nope, the TV is perfectly all right.
And you're correct: the bars are symmetrical, but the amount of info going into the top bar is sometimes huge, and must also be good readable. The buttons in the bottom bar are small, and the amount of text to be read is very limited.
So I would say: make the boom bar a bit smaller, and give that space to the top bar.

Choices, choices......

[Dream1975]

I see the skin now in the download section so I'll test it. I see 2 versions (see screenprint), why is this and will the skin be automatically updated when there are new versions?

Attached Files

•  Knipsel.JPG   15.23KB   48 downloads

[littlesat]

That is because it is on the 3rd party server and in the normal feeds (yesterday in the afternoon I was not sure it will made the currect way to get on our feeds yet).... From tomorrow that will be fixed.

The git24 is from the 3rd party feed... so please use the git25 version for now...

Edited by littlesat, 13 February 2013 - 10:49.

[BuGless]

So, in short, the only logical conclusion would seem to be that having those extra TEXT, INFO, MENU buttons on screens is of questionable value and merely clutters the screen needlessly in most cases.

That's one way of looking at it. IMHO there are plenty of screens where it is not obvious that not shown buttons provide extra functionality/information.

But why stop at TEXT, INFO, MENU? That looks like just half a solution to me. Then I'd rather invest time in making sure that the help button works everywhere and shows *all* the buttons that are active; or does this work already?

There already is a generic way. The generic title of a screen is displayed in the upper right. If a screen does it differently and doesn't show up the right way, the screen/plugin needs to be fixed, not the skin. Most screens get it right.

But as it is now you use one of the two options ('title="XXXXX" or the widget 'source="Title" render="Label" '), depending on the specific screen.
Given the fact that you made the colour buttons generic, I would have expected the same here.

Well, I think I assumed that, if, in a screen, a title="" is specified on the screen definition, that, it would suffice to display whichever comes through there. Which then implies that, if, some screen uses some alternate method (like source="Title") to attempt to influence the displayed title, that there need to be changes to the way this widget works; i.e. it should modify the title normally specified through the screen definition. As soon as this has been fixed, it will work for all screens. I assumed things already worked like this, so I didn't check/fix this. It does not require changing the skin though, just the code somewhere.

[BuGless]

the amount of info going into the top bar is sometimes huge, and must also be good readable. The buttons in the bottom bar are small, and the amount of text to be read is very limited.
So I would say: make the boom bar a bit smaller, and give that space to the top bar.

Ok, now I understand what you mean. The legend bar at the bottom could be made a bit smaller, but heights need to be specified relative to a font size, and currently the system only supports integer factors, so I'll have to check how this can be adjusted without sacrificing scalability.

With respect to the title bar at the top; even in its current incarnation, using the fontsizes which are present now, can you give an example where anything in there would be/become unreadable?

[Rob van der Does]

But why stop at TEXT, INFO, MENU? That looks like just half a solution to me. Then I'd rather invest time in making sure that the help button works everywhere and shows *all* the buttons that are active; or does this work already?

Well, first of all those three buttons are the most commonly used. Only in a very few screens more/other buttons are in use.
But more important: an on-screen button makes it very clear that there is a button that can be used. Do you think users will use the help-key on every screen, only to find out that in most cases no other buttons then the colour buttons are in use? In other words: showing the buttons in use is IMHO the most user-friendly way to show options.
But of course: it's your skin, your design.

Well, I think I assumed that, if, in a screen, a title="" is specified on the screen definition, that, it would suffice to display whichever comes through there. Which then implies that, if, some screen uses some alternate method (like source="Title") to attempt to influence the displayed title, that there need to be changes to the way this widget works; i.e. it should modify the title normally specified through the screen definition. As soon as this has been fixed, it will work for all screens. I assumed things already worked like this, so I didn't check/fix this. It does not require changing the skin though, just the code somewhere.

Not 100% sure I understand what you mean: you are already using one of the two options, depending on the screen.

With respect to the title bar at the top; even in its current incarnation, using the fontsizes which are present now, can you give an example where anything in there would be/become unreadable?

I find it already difficult to read in normal screens, such as the channel list. I'm not sure any more, but can it have been a messagebox (simple) or a textbox, where more info has been displayed in the top bar?
And the top bar is partly gray, partly black.


 Scale-HD 02.jpg   115.09KB   67 downloads
I noticed that 'VideoTune' has a rather different screen

 Scale-HD 03.jpg   155.52KB   68 downloads
What is the idea of all the small text in the about screen (see attachment)?

[BuGless]

But more important: an on-screen button makes it very clear that there is a button that can be used.

Yes, well, it sends me a message that says: This is a button you can press, but I won't tell you what it does, just try it.
It also implies that other buttons have no effect, which is confusing.

Do you think users will use the help-key on every screen, only to find out that in most cases no other buttons then the colour buttons are in use? In other words: showing the buttons in use is IMHO the most user-friendly way to show options.

I think we'd have to ask users that have thus far used normal TV-sets, to see if it helps them or not.

But of course: it's your skin, your design.

Well, no. It's our skin, our design, I'm just compiling input. It's a community effort, I'm merely the catalyst. That's the reason we have these conversations, to collectively improve on the design.

> Not 100% sure I understand what you mean: you are already using one of the two options, depending on the screen.

I'm just displaying the default screen title in the upper right corner. If the plugin wants to influence it, it should use proper widgetry to set/alter the default screen title.

>> With respect to the title bar at the top; even in its current incarnation, using the fontsizes which are present now, can you give an example where anything in there would be/become unreadable?
> I find it already difficult to read in normal screens, such as the channel list. I'm not sure any more, but can it have been a messagebox (simple) or a textbox, where more info has been displayed in the top bar?

If there was, then it was a mistake. Please report those.

> I noticed that 'VideoTune' has a rather different screen

That is one of the non-translated screens. It still uses the old templates and code. They're easily identified by the larger top/bottom bars, or in the skin.xml file, they're the screens that do not start in the first column of text.

> What is the idea of all the small text in the about screen (see attachment)?

That's (temporarily) for calibrating font sizes. Eventually it will go away and we'll teach the system to determine font dimensions by itself.

[Rob van der Does]

Not sure if we speak the same language here:

But more important: an on-screen button makes it very clear that there is a button that can be used.

Yes, well, it sends me a message that says: This is a button you can press,

Well, IMHO that's very good!

but I won't tell you what it does, just try it.

OK, there indeed a good help-function would be useful.

It also implies that other buttons have no effect, which is confusing.

And that's indeed the case, so why would that be confusing?

[Dream1975]

On both my ET9000 and DM800 the txt subtitles are too low (see screenprint).

Attached Files

•  screenshot.jpg   121.28KB   48 downloads

[BuGless]

but I won't tell you what it does, just try it.

OK, there indeed a good help-function would be useful.

It also implies that other buttons have no effect, which is confusing.

And that's indeed the case, so why would that be confusing?

Basically, what I would expect (if I imagine to be a typical user that has used plain TVs before, and is having his first day with enigma) in an ideal world:
- All buttons on the remote should do something meaningful on every screen.
- Whenever I press a button that has no function, treat it as the help button (and ultimately make it configurable, so that if someone doesn't like this, the triggerhappy help can be turned off).
- The function of a button should be guessable (at every screen) from the text or symbol on the button.

If one considers some buttons (INFO/TEXT/MENU) to be intuitive enough that they do not need a legend to explain what they do, then by the same reasoning one could say that if their meanings are so intuitive, then why does it still need to be shown that the button can be pressed at this point at all? It should come natural to the user that it can be pressed, because the meaning is implicit, so showing that pressing it is an option is superfluous.

With respect to the "confusing" part, I find (too often) that more buttons are available.

Edited by BuGless, 13 February 2013 - 18:37.

[BuGless]

On both my ET9000 and DM800 the txt subtitles are too low (see screenprint).

I just checked with the PLi-HD skin, there is a screen called SubtitleDisplay; and it basically is the same in both PLi-HD and PLi-Scale-HD. So I'd guess this is not something the skin causes, you can adjust the height of the subtitles in the configuration. Or do the subtitles jump back to their old spot as soon as you switch skins?

[Dream1975]

As soon as I switch from PLi-scale-hd to the standard PLi-hd screen the subtitles are in the right spot again so it seems skin related.

Most English channels (BBC/ITV) have txt subtitles, so maybe you can reproduce it with one of these channels (selecting the txt subtitles instead of DVB).

Ps. When playing a recording there is a Picon in the screen (but no Picon available so it is a white square). In other skins the Picon isn't there. Not a biggy, but I'd thought I'd mention it.

[Rob van der Does]

If one considers some buttons (INFO/TEXT/MENU) to be intuitive enough that they do not need a legend to explain what they do, then by the same reasoning one could say that if their meanings are so intuitive, then why does it still need to be shown that the button can be pressed at this point at all? It should come natural to the user that it can be pressed, because the meaning is implicit, so showing that pressing it is an option is superfluous.

Well, that's where I disagree.
The buttons INFO/MENU shown on the screen are quite meaningfull. But how should one be able to guess if a context-menu or an information-screen would be available if those buttons don't show?
Just go through all the screens and see if you're right.

Edited by SatKiekerd, 13 February 2013 - 19:32.

[littlesat]

With what did you create those dutch subs on a non dutch syfy channel?

[Dream1975]

With what did you create those dutch subs on a non dutch syfy channel?

I didn't, I both have Ziggo and CDS on my 8000 (and Ziggo still does have the Dutch SyFy)

Edited by Dream1975, 14 February 2013 - 08:14.

[littlesat]

And with Ziggo you can customize the subtitles?

But I have an idea what could be the issue here... the skin has an different resolution and that subtiles are therefore scaled incorrectly...

Edited by littlesat, 14 February 2013 - 10:48.

[pieterg]

txt subtitles do not have a resolution, they are rendered by e2 (on a subtitlewidget, which has certain dimensions, dictated by the skin)

[Dream1975]

And with Ziggo you can customize the subtitles?

Nope, with PLi-HD the subtitles are in the right spot, with PLi-scale-HD they are too low (I dont customize anything, just switch skin)

[BuGless]

The buttons INFO/MENU shown on the screen are quite meaningfull. But how should one be able to guess if a context-menu or an information-screen would be available if those buttons don't show?

The premise of a proper UI is simple: ask all clueless users to tell you what they would have expected if they were to press these buttons at this point; if you get a >90% score of the same action, implement it. The best UIs don't need explanations or documentation. But I'll keep your remarks in mind, if a simple method becomes available to automatically display some of those extra buttons, I'll see if I can fit them in somewhere.

You're saying that the description area almost touches the channel list; does that mean that you'd like a larger gap there for better readability?

I sure would. The present 'lack of gap' makes it hard to read.

I increased the gap on the ChannelSelection screen, and I noticed that I (by accident) omitted the gap on the EPGSelection screens. Both are synchronised now (updates in tomorrow's build).

As soon as I switch from PLi-scale-hd to the standard PLi-hd screen the subtitles are in the right spot again so it seems skin related.

Still looking for this one. Seems like I have to look in the source, in the skin it does not seem to be an obvious tweak.