[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-panel-devel
Subject:    Re: [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"> &gt; <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>
&gt; For the controls (rotate, re size, arrow), are they displayed on mouse over<br>
&gt; 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>
&gt; Also how would this layout perform using clone mode? One display would be<br>
&gt; below and unelectable. Unless then overlapping, some popup could came up and<br>
&gt; 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 &quot;clone display&quot; rather than<br>
showing the individual displays.<br></blockquote><div><br>Alternate layout for cloned \
mode added in the mock. <br></div></div>



_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel


[prev in list] [next in list] [prev in thread] [next in thread]