[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-usability
Subject: [KDE Usability] Re: Display Management Design
From: Lukas <1lukas1 () gmail ! com>
Date: 2011-07-30 21:19:39
Message-ID: CAHtHk47sg3FQEi0tKmp72V8GY-qGetXihsx8_ikfSVfoCXdHHg () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
> >
> https://docs.google.com/drawings/d/1A7bdmsLBE_oeRZPHxZNMBVAxMQZCkQIclWOrd2mRLGs/edit?hl=en_US
>
> Close. A few things:
>
> I would move the list of activities to the top right, using a drop-down
> list.
>
I tried, but such layout look unbalanced. Those 2 lines of preferences gives
just the right weight for the UI.
> > For the controls (rotate, re size, arrow), are they displayed on mouse
> over
> > or always?
>
> Always. Because of how other interfaces work on past experience,
> users are unlikely to try to interact with the screens unless they
> have some clear indicitation that they should
>
The difference with previous experiences - current mock has close to no
options that user could try to change. In combination with the size (like
60-70% of window) is preview widget, I personally believe there is no way
user wont try to hover the monitors. Otherwise there is nothing else to do.
In unknown situations people just starts experimenting
>
> > Also how would this layout perform using clone mode? One display would be
> > below and unelectable. Unless then overlapping, some popup could came up
> and
> > let user to select display in the background.
>
> If they are different sizes, the smaller one would be on top always.
> Otherwise it would probably show as a "clone display" rather than
> showing the individual displays.
>
Alternate layout for cloned mode added in the mock.
[Attachment #5 (text/html)]
<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 \
.8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im"> > <a \
href="https://docs.google.com/drawings/d/1A7bdmsLBE_oeRZPHxZNMBVAxMQZCkQIclWOrd2mRLGs/edit?hl=en_US" \
target="_blank">https://docs.google.com/drawings/d/1A7bdmsLBE_oeRZPHxZNMBVAxMQZCkQIclWOrd2mRLGs/edit?hl=en_US</a><br>
<br>
</div>Close. A few things:<br>
<br>
I would move the list of activities to the top right, using a drop-down \
list.<br></blockquote><div><br>I tried, but such layout look unbalanced. Those 2 \
lines of preferences gives just the right weight for the UI.<br><br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: \
1px solid rgb(204, 204, 204); padding-left: 1ex;"> <div class="im"><br>
> For the controls (rotate, re size, arrow), are they displayed on mouse over<br>
> or always?<br>
<br>
</div>Always. Because of how other interfaces work on past experience,<br>
users are unlikely to try to interact with the screens unless they<br>
have some clear indicitation that they should<br></blockquote><div><br>The difference \
with previous experiences - current mock has close to no options that user could try \
to change. In combination with the size (like 60-70% of window) is preview widget, I \
personally believe there is no way user wont try to hover the monitors. Otherwise \
there is nothing else to do. In unknown situations people just starts \
experimenting<br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; \
border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> <div class="im"><br>
> Also how would this layout perform using clone mode? One display would be<br>
> below and unelectable. Unless then overlapping, some popup could came up and<br>
> let user to select display in the background.<br>
<br>
</div>If they are different sizes, the smaller one would be on top always.<br>
Otherwise it would probably show as a "clone display" rather than<br>
showing the individual displays.<br></blockquote><div><br>Alternate layout for cloned \
mode added in the mock. <br></div></div>
_______________________________________________
kde-usability mailing list
kde-usability@kde.org
https://mail.kde.org/mailman/listinfo/kde-usability
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic