Date: prev next · Thread: first prev next last
August 2013 Archives by date, by thread · List index


Hi Siqi,

On Sun, Aug 18, 2013 at 7:51 PM, Siqi Liu <me@siqi.fr> wrote:

Hi Mirek,

Sorry for the late response. I was trying to stay focused on the Bonjour
support for Windows and now I can move on to more UI/UX improvements.

2013/8/13 Mirek M. <mazelm@gmail.com>

Hi Siqi,

On Sun, Aug 11, 2013 at 4:06 AM, Siqi Liu <me@siqi.fr> wrote:

Hello Mirek,

What's your take on the new screens? Eager to hear from you on them.


You can find them here:
http://siqi43.wordpress.com/2013/08/10/a-slightly-flattened-version-of-ios-impress-remote


I'll just go through them:
The Connection screens:
* What is the purpose of having a screen with a single button on it on
the tablet? Could you please just show the computers to connect to right
away, as I assume you do on the phone?


Yes, I basically used this screen to provide a background for the pop up
modal views. I can fire up the modal views right away and keep the orange
background only (without icon, connect button and app title, or any
suggestion on what kind of background to use? ). But in that case, there
won't be a "cancel" button on the server list page because we must keep the
modal view open if we don't have a button to reopen the server list page.
We are therefore forcing users to open this modal view in a sense... That's
my only concern here but I can definitely do this if it doesn't bother you.


It doesn't bother me.



 * If you decide not to, please at least make it look like the Connect
button is tappable, and it would probably be good to use the whole Impress
remote icon graphic rather than a cut-out square (it makes sense in an
icon, but looks odd when there's ample room for it not to be cropped).


I think I will remove this page then, by keeping the orange background
only.


Great. :)



 * The text on the PIN screen should read just like how you would say it
in real life. Try "In Impress, go to "Slide Show -> Impress Remote" and
enter the PIN [1678]." The string "Waiting for validation from Impress..."
isn't necessary unless it takes a long time to validate.


Well, this depends on how fast users enter the PIN code on their PCs
actually... I will remove it if it seems to be unnecessary. By "Waiting" I
actually mean that the app is waiting for pin pairing from users.


Ok.
I'd vote for removing it, then.



 * It'd be better to not have the presentation preview page and just
start the presentation right away. The page is just an unnecessary extra
step.


Euh...but what happens when the iOS device first paired with the PC? It
starts the presentation right away without asking if the user want to start
it? And where should I put those configurations or they are unnecessary as
well? I was keeping it because 1) the Android app has it as well 2) This
gives users a chance to do some configuration and only start the
presentation when they are ready. I don't think one extra step which helps
to make sure the right presentation is running and all the config are right
in place would bother the lecturer... if you are in front of several
hundreds of people you don't want to make any mistakes ... that one extra
assurance weighs heavier than one extra tap on the screen as far as I am
concerned....

Anyway my opinion might be subjective, but I really can't remove it before
changing the protocol, which needs some kind of consensus with the android
app as well.


That's odd -- when I tested Artur's Android app, it didn't show this screen
and instead jumped right into the presentation. Has that behavior changed
now?

If not, it'd be good to be consistent in this case.

The presentation screens:
* Where is the pointer button on the tablet?


There isn't one. If you touch the preview image (and the preview/next
button on the side will become transparent), you get the pointer. Since
it's large enough for users to use their pointer, it's unnecessary to add a
button for that effect. (on iPhone the Pointer button was used to show an
enlarged preview image)


I have a few concerns about this:
* Is it discoverable? How does the user discover that there is a pointer
feature?
* When we enable clickable elements on slides, how will those be activated?
I was hoping they would be tappable.



 * The Options button looks way out of place on the tablet. Please at
least keep its background white or light gray.


I am such a bad designer :-P, I was trying to reproduce the black side
list like the one from this post on 
theverge<http://www.theverge.com/2013/8/15/4623016/buying-a-laptop-everything-you-need-to-know>.
It was shown on the left when you scroll down to the main article. Whenever
you click on the gear, it will slide to the left a little bit and show the
popover. When the popover is dismissed, the gear will slide back to the
right. But yeah, now looking back, the coloring doesn't seem right. I will
change that.


Ok, good.


* The Pause and Clear buttons are really hard to see. Since the app
doesn't use TextKit, therefore not being able to tap into iOS 7's font
accessibility options (I assume), it'd be good not to use Helvetica Neue
Ultra Light at all. The Pause button should also have a different color.


That was already Helvetica Neue (without Ultra) Light I think. And I'm
kind of into a dilemma now... here is a screen from iOS7 of Apple's new
clock app (I did my circle button design before noticing this :-P). Apple
apparently resizes the text in order to put all text into the circle when
translated to other languages.

[image: Images intégrées 1]


 I've also tried to replace the text with icon, which gives us this:

[image: Images intégrées 2]

Which way should I go then? Rounded-rect button with text? circle button
with text? Or Circle button with symbols?


Symbols sound good. :)

I'm wondering about the behavior of the "Clear"/"Stop" button. While I
would expect both to do the same in a stopwatch, in a timer, I would expect
"Stop" to go to the original time set, but I would expect "Clear" to set
the value to zero. "Stop" makes much more sense to me in this case, so I
hope that's the case. The icon seems to indicate so, but the former label
confused me.

Does the green color of the Play button indicate that it's active or is it
simply a highlight? (It would be clearer to show the Pause symbol instead
if it's the former, color it gray if it's the latter.)

Also, how is the timer set?

 * The "More" label in the More menu is unnecessary and looks like a
command at first sight.


Agree with you. Removed.



* I don't particularly like the idea of having the slide picker onscreen
all the time, but that's a subjective feeling.


On iPad it seems to make good use of the available space. Also I couldn't
come up something to put in place of the slide picker...and it would be too
large if I enlarge the slide preview image even more.


Ok.



 * The slide picker should have the same aesthetic as the rest of the
app.

Noted, I will do some tweaks on that.


Thanks.



* The slide preview itself looks stretched out and blurry -- I assume
that's a bug that will be fixed, right?


I would say it has become a bug now :-P
In older implementation for the remote control was only designed for
phones. So the images sent from computers are only big enough for phones
which helps to reduce the traffic over the network when sending them to the
phone. Now with iPad....well that's no longer "big enough".

I've proposed to change this by adding a param during the hand-shake
period (by specifying a "small", "medium" or "big" screen size parameter
for example). But I would need Artur's confirmation in more details on how
to implement this. I've cc Artur as well.


Great.


In general, I'm not too keen on the iOS7-esque look. It feels kind of
like iOS 7, but not quite there (the fonts sometimes have different
weights, the icons are thicker and have a different style, the slide
sidebar keeps its iOS 6 look, ...), and it might feel sloppy when
juxtaposed with built-for-iOS7 apps.


If we want the app to stay consistent on iOS5/6/7, then we would be
obliged to do some really deep customization... in iOS7 the app will have
iOS7 styled slide sidebar so it shouldn't look too strange when compared to
other iOS7 app. But...on iOS6 I must say that it's kind of weird to have a
iOS6 tableview side-to-side to an iOS7 style navigation bar...

For now I think I will check all the fonts to use Neue Light instead of
Ultra Light and try to do some customization for the tableview. I would
love to have a more complete UI customization implemented but that would
require not only too much work but also too much design genius from me as
you can tell now :P


:) ok



 That said, I'm not really sure what the best solution here would be.
IMHO, it might be best to have our own consistent style on iOS like Google
does, but I understand that's a big undertaking and it's not something I'd
like to work on. I'm hesitant about fully embracing the iOS7 look, given
the accessibility implications. I guess we could embrace that look where
possible, but use Helvetica Neue Light instead of Ultra Light.

Do you want me to tint all buttons/icons in orange to stay in line with
the Android app? I've taken blue only because it's one of the default on
iOS7.


Yes, please tint them.


Also, Fitoschido <http://fitoschido.wordpress.com/> has made a good
point in his comment I think. What's your opinion on that?


I agree that the iOS7 design is unfortunate in this case, but I feel like
using icons instead would be sacrificing clarity, at least in the case of
the button "Clear" (oh, the irony).
I'd recommend to use a thicker font weight, more visible colors (how
about orange for both), and delineate the button with a round rectangle
instead of a circle (you never know how long translations will be and if
they'll fit). Or you could just not have any delineation for the buttons
whatsoever -- I guess that'd be the better choice for iOS 7.


Please take a look at the screens above. Give me your final conclusion and
I will do that ^^


Screens look good, though I could do without the fluorescent green.
:)

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.