Paroli Theme/UI proposals

[EdorFaus]

Laszlo KREKACS wrote:
> 1: Try to put these pictures on the Freerunner, to see how it feels.
> There are view
> image viewer out there, or you can even write a simple elementary
> application for it.

Did you try this yourself? I just did.

(I used Neon (package om-neon) as image viewer, clicking the button for 
1:1 size, scrolling up and down as needed to see everything.)

> On my 15.4" laptop, the freerunner screen is equal to a 176x235 pixel rectangle.
> So if you scale your images to this size, you can observe a few things.

> To demonstrate it, here is a resized, blurred image (just apply
> gaussian blur in gimp):

This approach doesn't work. Especially the blurring is wrong.

The Freerunner screen has a lot more pixels in the same physical size, 
so it is much sharper than your computer screen - resizing down like 
that loses information, and then the blur makes it even worse, and moves 
the result even further away from the FR's screen.

Basically, to see what it's actually like, using the Neo itself (or 
something else with the same kind of high-DPI screen) is essential.

> Lets talk about the main screen:
> http://jonkristian.no/wp-content/uploads/2009/08/main.jpg
> 
> Apart from the clock, none of the texts are readable. I can read some,
> if I seriously
> try, but my mom cant read it for sure.

For me, on the actual FR (instead of your blurred image, which isn't 
representative at all IMHO), most of the text on that image is easily 
readable at arm's length for me.

The only things that are slightly hard to read are the next/previous 
texts at the very top. Holding the FR closer, like I would in normal 
use, I don't have a problem reading those either. Also, they have more 
than enough space around them to be enlarged if necessary.

The text on the icons is the same size, and isn't really a big problem 
either - especially since you'll usually remember the buttons by the 
icon without needing to read the text. They don't have quite as much 
space to be enlarged in though.


However, the text in the information bubbles (see for example the
http://jonkristian.no/wp-content/uploads/2009/08/telephony_info.jpg
image) seems a bit too small to me.

While I can read it, I have to hold the screen rather close to do it 
comfortably, and wouldn't bet on anyone much older than me being able to 
read it at all.

I'm not sure if it's really any smaller than on the icons, but they use 
only capital letters, making it seem larger, and have more space around.

The 4 lines of information is most likely the biggest problem, as it 
forces the text to be too small and dense for it to be very readable.

I guess that 2 lines would probably be enough for the purpose of making 
the most essential information be visible quickly, while allowing the 
text size to be readable. 3 lines *might* work.

Information density, while good, is not the most important aspect here.


> 3. No idea what is the 23 number of the upper left corner of clock.
> Should be 42, no?;)

I'm guessing that this is the seconds - which, if I'm right, would be 
obvious in the actual interface. :)


> 4. Although Im not a designer at any means, but I think the pixelized
> icons does not really
> much with the smoothed texts.

I'm not a designer either, and don't usually care much how things look 
as long as they're usable. So you should take everything I say with more 
than the usual grain of salt, enough possibly to cause sodium poisoning, 
utterly breaking down the entire metaphor...

In this case, it seems mostly just a somewhat retro look, with icons 
that should be recognizable from lower-resolution devices, without 
artificially making the text harder to read. Looks fairly good to me.

In any case, I'd guess that the icons should be fairly easy to theme 
without changing the rest of the interface.

> 5. The displayed numbers of incoming and outgoing calls are almost
> unreadable. Should be way bigger.

While I don't think it's unreadable, I also feel the number should be 
quite a bit larger, especially on incoming.

On incoming, I see the reason why the keypad is there, and the 
accept/reject buttons could use some more size to be easy to hit.

The image of the person, too - as is, it's so small that you can't 
really recognize the person IMO.

I don't see the name anywhere, shouldn't that be displayed too?
(I assume the caller must already be known, since there's an image...)

In the phonebook (phonebook.jpg image), I feel the size of the name 
should be larger than the size of the phone number, as I think it would 
usually be the name you're looking for (so that's the more important bit 
of information). Or at least the same size as the number.

----
OK, a new message popped up while writing; responding to that now, as 
it's rather related...


Jon Kristian Nilsen wrote:
>  my mockups contains elements that
> for sure needs to be taken care of in the code,
> this includes, if im not mistaken, text styles, sizes, shapes of boxes
> etc...

> See my first comment. Text size should be considered at a later stage, also,
> this is easy to change in code.

While text sizes and such definitely need to be taken care of in code 
(otherwise they'd all be the same default size), I think that the text 
size especially needs to be a part of the design and usability stuff.

In large part this is because there's limited space available, so just 
enlarging the text later might break parts of the design (e.g. starts to 
overlap icons or other text, or needing more than one line to fit).

Sure, it doesn't have to be exact, small adjustments should be easily 
doable later - but the major relationships should be clear beforehand, 
so the display layout and code can be made appropriately.


As an example, we can look at the 4 lines of info you have in the 
bubbles - with a larger text size, you wouldn't be able to fit 4 lines 
in there, so would have to show the info differently or drop some of it.

Similarly for the phone number displayed on incoming calls - making it 
larger would require more space, and especially for long numbers it 
could be a good idea to wrap instead of just going off the side so not 
everything is visible, but that requires multiline support - which might 
not be implemented at first if the design doesn't appear to need it.



Disclaimer: I'm not a Paroli dev, and don't have all that much 
experience with E, so I could easily be wrong about some things.

--
Frode Austvik