On 30.04.2012 11:35, Marco Martin wrote:
On Sunday 29 April 2012, Thomas Pfeiffer wrote:
3. Remove the label Lock as private from the switch. Instead, put icons
similar to http://dribbble.com/shots/415967-Privacy-Settings on the
corresponding sides of the switch
4. Move the private switch next
Sorry, I forgot something: Please also change the label of the Close button to
Cancel. A Close button implies that pressing the button has no other effect than
closing the dialog (whoch is the case in instant apply dialogs). However, in the
Task Dialog case, any changes made will be lost, so
On Monday 30 April 2012, Thomas Pfeiffer wrote:
First of all: I think it looks a lot nicer now, much cleaner and less
verbose. :)
I agree that the row with the name and lock widgets does not look well
balanced right now. I wonder if it would look less - or even more -
unbalanced if you
On 30.04.2012 14:26, Marco Martin wrote:
probably worse... maybe restore the Activity name: label with some tweaks to
make it as wide as the switch, so would center the text field again
Would Name also work, perhaps? Or is it too short to counterbalance the
switch? Aaron and Fania expressed a
On Monday 30 April 2012, Thomas Pfeiffer wrote:
On 30.04.2012 14:26, Marco Martin wrote:
probably worse... maybe restore the Activity name: label with some
tweaks to make it as wide as the switch, so would center the text field
again
Would Name also work, perhaps? Or is it too short to
Hi all,
after the long and heated debate about the changes to the Activity
Configuration UI suggested by Aaron seems to have settled, it seems unclear
what we actually want to change. In order to allow actual changes to happen, I
have extracted from the discussion the things I think we agreed
On Friday 30 March 2012, Fania Bremmer wrote:
lock as private sounds awkward. How about a slider with (or as) an
unlock/lock icon and private to the the appropriate side of the
slider, similar to layers in Inkscape or objects in Scribus.
(Especially on small screens, the Inkscape method is
On 30.03.2012 00:32, Aaron J. Seigo wrote:
my concern is that this takes too much time to set up an activity and that it
also would deviate from the configure activity UI.
We actually wanted to come up with a more comprehensive concept before
presenting it to the list, but in order to make
On Friday 30 March 2012, Aaron J. Seigo wrote:
On Friday, March 30, 2012 10:17:15 Marco Martin wrote:
On Friday 30 March 2012, Aaron J. Seigo wrote:
the buttons in the title do work, indeed... i wonder if they make more
sense on the same side of the dialog together, but that's something i
On 30.03.2012 10:53, Marco Martin wrote:
however, if we do want to keep the close button and if we put buttons int
he title bar, it could be drawn exactly as we do the close button on
plasmoids.
I think we should just make a decision now.
Personally, I tend towards Either both buttons or none
On Friday 30 March 2012, Thomas Pfeiffer wrote:
On 30.03.2012 10:53, Marco Martin wrote:
however, if we do want to keep the close button and if we put buttons
int he title bar, it could be drawn exactly as we do the close button
on plasmoids.
I think we should just make a decision now.
On Wednesday, March 28, 2012 17:46:52 Fania Bremmer wrote:
implementation-wise. Now there comes in a new requirement, the smaller
screensize, and we need to find another good solution. I agree that for new
while the lack of elegance is more obvious at lower screen sizes, the lack of
elegance
On Wednesday, March 28, 2012 19:56:46 Thomas Pfeiffer wrote:
Generally when designers and developers meet, the developer is in the
stronger position.
this statement speaks to a large challenge we apparently face: seeing other
members in the team as people to be opposed rather than a team
On Wednesday, March 28, 2012 17:31:00 Sebastian Kügler wrote:
Does this make sense?
+1 from me.
--
Aaron J. Seigo
signature.asc
Description: This is a digitally signed message part.
___
Active mailing list
Active@kde.org
On Wednesday 28 March 2012, Sebastian Kügler wrote:
The general rule should be to not use Apply buttons, and for dialogs,
dismiss them when clicked outside. (This is btw also how the Harmattan
components work, and I think it leads to smooth workflows.) Note that
dismissing the dialog means
On Thursday 29 March 2012, Aaron J. Seigo wrote:
On Wednesday, March 28, 2012 19:56:46 Thomas Pfeiffer wrote:
Generally when designers and developers meet, the developer is in the
stronger position.
this statement speaks to a large challenge we apparently face: seeing other
members in the
On Thursday 29 March 2012 17:34:02 Marco Martin wrote:
On Wednesday 28 March 2012, Marco Martin wrote:
i still think the best way to still have buttons, have them always visible
and taking less space is having them in the titlebar, like the ipad and
the n9 do:
On 28.03.2012 14:11, Fania Bremmer wrote:
* change title to Activity Settings (settings being less tech than
configuration and shorter, at least in english; use title capitalization)
+1. I would even prefer a title that integrates a verb, like edit activity.
But that's a wording question. I
* change Lock as private to just Private. the phrase Lock as
private is
a bit awkward (it is not a natural phrasing one would use in
conversation) and
specifying Lock speaks to the mechanism rather than the intention
of the
user. the intention is this is private; the mechanism we use is
On 28.03.2012 14:37, Fania Bremmer wrote:
I don't really like Lock as private, but if that's the one that fared best
with the users, I think we should still keep it. Don't know what it looks like
if it's placed next to the name, though. Might make the row a bit too long.
Keep in mind that we
Em Wednesday 28 March 2012, Marco Martin escreveu:
On Wednesday 28 March 2012, Thomas Pfeiffer wrote:
Ah, I see.
So what is the internal, technical workflow for switching an activity to
private (everything that happens from the point where the user taps
Save in the Activity configuration
Am 28.03.2012 17:27, schrieb Ivan Čukić:
instant apply is really not a possibility here for technical reasons. we
can get rid of the Close button though by making an outside tap close
and cancel the dialog.
Okay okay, so no instant apply. But can we still open the password setting
dialog
Sorry, but that comment just made me laugh: we would write why it can not
be like that; that shouldnt be the focus in a multi-disciplinary team, that
designers propose something and the techies just say no, not working.
Honestly, I don't see anything amusing there. If a designer asks for
we would write why it can not be like that.
the key word being 'why' - reason for not implementing something,
since we are devels, the reason usually is technical. I know, I need
to be less zen and more verbose sometimes :)
Whenever UX people write something, the developers
always say that
24 matches
Mail list logo
