Re: activities
On 5 February 2010 18:44, Aaron J. Seigo wrote: > Context is specific to the person in that it is the person's current internal > state which defines which Context (if any) is applicable. it has nothing to do > with the computer. in fact, Context is a way to make the computer reflect the > person. you're suggesting we make the computer define the Context through a > visual representation, when really it's something that should be global to the > computer at any given moment. Changing context will alter the state of applications+plasmoids+desktop, so it's a highly modal feature. Modes are dangerous animals for interface users, but can be made usable with clear visual indicators. I also favor using a visual representation for Activities to clearly show which is the current one and how it affects the global computer state (mode). If Context is global to the computer, then use a global visual representation. Two possibilities I can think of for global representation of a modal state are: - spatial layout of the different modal regions - changing style (color, window decorations) The first one is is more effective in avoiding mode errors (actions by the user that don't make sense in the current mode but are valid in a different one), but changing style also have some merit - this is how tool palettes in graphic applications behave. Activities shown in the Concentrate demo video are complitely invisible except for the configuration dialog, and that's no good. >> So while in theory it makes sense to be able to merge vdesktops with >> activities, > > it doesn't make any sense in theory. It makes sense to have a physical representation for the abstract Activity concept. Merging them with VDs is just one way to make this happen, so it does make sense in theory. It just doesn't make sense in practice since it's not the best possibility; it merges two different abstract concepts into only one representation, which makes for an easy to break interface metaphor. > by making them easy to define and switch between. the defining bit is actually > going to be the hardest. if we wish to tackle an interesting set of unanswered > problems, that's probably where to head. Not only define and switch. You must also make it easy for the user to *think* about them. That is the hardest part. You need a simple mental model to explain what activities are, how can be used and why. If you need ten paragraphs of text instructions you have failed. That's where a physical visual representation would help, but we need one that doesn't conflict with the already busy Desktop metaphor. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Manual Hiding of Plasma Panel (desktop shell)
Hi, I'd like to step in to defend the interests of us KDE users who won't use this feature. I want to make sure that it can be configured to not interfere with my current workflow. My rational is that I've always found this KDE 3 panel feature a little bit annoying, and now the use case it provides (showing and hiding alternate panel configurations) is better supported by Activities in a more general way; so I won't have a need for manual hiding. When I'm low of screen space I've always used auto-hide anyway. One possibility is just having an option to disable it, and make "disabled" the default setting. Users who remember the 'hide' button from KDE 3 will know to turn it on, and those first introduced to KDE 4 won't find a feature that changes the previous behavior of hotspots like the panel edges and the screen border. But if the 'hide' buttons can be implemented so that they don't interfere with the current hot spots, I'm in to have them enabled by default. I liked the idea someone proposed to create those buttons as plasmoids so that each user can decide where to place them (either inside the panel or on the desktop). I'm concerned about the buttons taking the screen or panel edges, and/or displacing or overlapping the panel contents. If this is the behavior of this feature, I'd certainly ask to have an option to disable it completely. Thanks for your attention. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Manual Hiding of Plasma Panel (desktop shell)
On 5 March 2010 12:12, Diego Moya wrote: > I liked the idea someone proposed to create those buttons as plasmoids so > that each user can decide where to place them (either inside the panel or on > the desktop). > Oh - I forgot: another really good option is having the "hide" button showing only under the cashew. This way it doesn't waste screen space so it could be always available (no configuration option needed), doesn't interfere with the panel contents, and is integrated with all the other panel configuration features instead of being just another new inconsistent way to handle the panel. The icon for the closed panel could be the cashew as well. The only drawback is that it will need two clicks to hide instead of one. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: keyboard shortcut
I personally set up Win+Space as the shorcut for the application launcher in all the windowing environments I use. It has nearly the same convenience as Alt+Space, and I've found that the Super-Meta-Win key is less overloaded with key combos than Alt - so I can use it without running into any conflicting usage in other applications. The Win key is also associated with launching apps in That Other environment (where it opens the main application menu with the matching icon), so most users will already associate this key with the functionality provided by Klauncher. The mentioned Wikipedia article says Win+Space is be used for Maximize vertically, but it's not working in my default Kubuntu installation (actually, neither Win nor Win+Space are tied to any function by default, is that an Ubuntu-only thing?) Martin Gräßlin wrote: >As an old Katapult user I personally would love to have alt+space as the >shortcut for KRunner, but I don't think it's a good idea to change a shortcut >probably known to all KDE users. I also previously used alt+space but was bitten by the conflicting bindings in other applications. I then discovered that I could made the switch to Win+Space easily. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: n+1st report about arrow keys in krunner
On 28 February 2010 09:34, Aaron J. Seigo wrote: > On February 27, 2010, Miha Čančula wrote: > > I suggest that the history should be added as just another runner. It > would > > show the last N used things when started, and then display a filtered > list > > when you write something. > > which does not address the issue of the interface by which to show such > history without getting in the way of actual results that match what is > currently being typed. > > Having separate lists for history and search results in the same widget is going to have usage problems, no matter what you do to invoke them. Information retrieval theory shows that the user doesn't care searching through history and searching through the list of pre-stored items, it's all the same. This is why you see unified interfaces popping up everywhere (Lancelot, Firefox Awesome bar, Mac Os X Spotlight, Gnome Do). Every search function I've seen that does this right follows more or less the same pattern: 1- Down arrow on the empty text field shows either a list of recent searches, or the selected result in recent searches. The first item is selected and the text box is updated with the item content. (If the item contains a description, then the text field contains the command name) 2- Typing begins a search, showing results in the same list as in step 1 but filtered to match the typed characters. Results from history that match the characters are also shown in the list. 3- Down arrow moves to the first element in the list, and the text box is updated with the item content. The focus is ALWAYS on the text field. 4- Even if an item in the list is selected, typing new characters add them to the end of the current text field contents. 5- Tab is a synonym for the down arrow, they work exactly the same in every possible state. This works to avoid ambiguities. (An alternative is not to update the textfield content when pressing up&down, and having Tab to replace the field contents with the command for the current item). 6- Pressing the Up arrow when standing in the first item in the list restores the original characters, exactly how the user typed them (except after step 4, in which the content is the whole command name plus the last typed characters). ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: n+1st report about arrow keys in krunner
On 8 March 2010 01:42, Aaron J. Seigo wrote: > this reminds me about jokes about the difference between theory and > practice. > > if we remove the history then we'll get to deal with tons of bug reports > about > how you can't do "alt+f2, up arrow, enter" which is a very, very common use > pattern. > > Who says you can't do that? What you *shouldn't* do in this context is opening a different list when pressing Up and when pressing Down. You still can open the list when you press Up. that theory of "history isn't used" is, in the face of real world practice, > dead wrong. > I dind't mean "history isn't used", I meant "history is not separate from bookmarks", which is what the *practical* experiments performed on browser history showed. > > > Every search function > > krunner is not a search tool. it can be used to search for things, but > that's > not the extant of its definition. > If it can be used to search for things, it's a search tool - whether the designer wants it this way or not. It's the user who decides what the tool does for them, not the programmer. If it has a search function, someone will use it for search. If the search tool conflicts with the tool's primary goal, either remove the search functionality or make it not conflicting. There's a standard interaction for "history+search from a predefined list". I say don't reinvent the wheel, use the existing expected interface - or turn it into something other than history+search. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: n+1st report about arrow keys in krunner
On 8 March 2010 23:39, Jacopo De Simoi wrote: > This also definitely implies that it can be used as a search facility, it's > not its main purpose but it does not necessarily conflict with the primary > goal; in fact I find it a very useful tool. > I agree with that. It's not the search function that conflicts with the primary function as a launcher, it's the search *interface.* The issue here is imo the fact that the examples of 'history+search from a > predefined list' you are taking do not refer to a history of queries (such > as krunner history), but rather to a history of results (such as firefox > history). > This complicate things quite a bit, since there's not anymore a one to one > correspondence between history elements and results, but each history > elements provides in principle a number of different results. > I am not able to see how they should apply to our case, unless we are > willing to implement krunner history as an history of "recent results" > rather than "recent queries". Whether we should or not, I guess it's open to > discussion... > > I'm not asking for a change in functionality. I'm arguing for a change in presentation. Having separate interfaces for retrieving previous queries and for selecting launcher items does cause interaction problems, as shown by the issues in this thread. The solution I'm arguing for is disabling the auto-complete history feature provided by the combo box, because the interaction style provided by the widget is conflicting with the rest of the application. This means reimplementing exactly the same functionality in the main list, showing previous queries together with applications that both match the new typed search string. You could show recent queries at the bottom of the list - this way pressing Up wraps around the list and places you at the bottom, right on the most recent query, while pressing Down places you on the first search result. Same functionality, same keys, a much simpler interface. It's sad that standard widgets functions can't always be reused, but this time it's necessary for a smooth integration - the existing code for query history is not providing a good interface and is inducing user errors, so IMHO it shouldn't be used in this case. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: n+1st report about arrow keys in krunner
On 9 March 2010 17:54, Aaron J. Seigo wrote: regardless, there are ways of doing the keyboard interaction with the > current > set of widgets that will work. i'm not interested in breaking the history > feature on those who use it and rely on it just to reach some search-tool- > purity. > Neither do I - I'm interesting in fixing the history feature for those users who filed bug reports because of the confusing interface, not in removing the feature or altering the valid workflows. > > and let me say it one more time: krunner is not a search tool. > and again: krunner is not a search tool. > Half the meanings of a software product are provided by the user when trying to make sense of the interface. The designer doesn't decide what the tool is used for. The designer doesn't decide what the tool is used for. I know how to repeat myself too. ;-) (Besides, the krunner page at Userbase disagrees with you): http://userbase.kde.org/Tutorials/Krunner "Krunner is tool for searching and launching files and applications..." > what is it then? it is the evolution of kde2/3's "run command" dialog. and > that use case must still be preserved. > > Again, I'm not trying to change the use cases and turning krunner into a general desktop-wide search - I use Lancelot for that. I'm trying to provide a better interaction for the existing user case, one that doesn't create two different lists depending on the key you press (Tab or arrows) and the state from which you start (empty box or some characters already typed, though this criteria could be used if both lists can't be integrated into one). This should improve learnability - people wouldn't need to be told that "Tab changes focus to the results list" after they try to use the down arrow and it doesn't work as expected. The whole point of this thread as I see it is that the user shouldn't use different keys for the history and result lists - they should be used exactly the same, either if both lists are merged or if we have a "history only" list (when the text box is empty) and a "results only" one (when typing). > On March 9, 2010, Diego Moya wrote: > > reimplementing exactly the same functionality in the main list, showing > > previous queries together with applications that both match the new typed > > search string. > > the whole point of history is so you don't have to type. if you have to > type > to match the history, then there's no point in having the history, is > there? > There's one, auto-complete. Right now you type "ama"... and the box field suggests ..."rok", which you should get completed with the Tab key. But this can be sacrificed if filtering history results is too hard to develop - showing the history list only when the text box is empty would be a good compromise solution. one compelling suggestion i've seen is to put the last N selected items in > the > listing by default when shown. this was meant to augment the history not > replace it, and won't work nicely with an always-shown krunner, but it is > an > interesting idea. > I'd suggest showing the last N history items when you press Up or Down keys when the textfield in empty, or maybe as soon as krunner gets focus. This would also work for the case when krunner is always shown. moreover, if history is shown below then we'd either show only the match > that > was actually activated (a possibility, but also a significant change in > behaviour) or it becomes a two step process where the first step is "select > the history match" which would then cause another run against it and then > "select the match that matches the history match" once the returns are > made. > Does the current textbox's history not filter already by the typed prefix? I'll have to check it this afternoon. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Questions about plasma notifications
Shouldn't that question be cross-posted to kde-usabil...@kde.org to have more eyeballs? :-) On 14 March 2010 23:50, Eduardo Robles Elvira wrote: > In Artesanos we are working in the new KDE Bluetooth stack > > * Job Finished notification > > When a Job takes less than X seconds (currently, 1.5s) to finish, no > notification is shown. And that's ok and has been discussed before: we > want to bother the user as little as possible and a notification that > happens for less than 1.5 seconds doesn't makes sense. But what about > the "job finished" notification? That one doesn't have a > time-constrain, and is equally useful independant of the time the job > took to finish. > Actions under 1.5 must also have feedback, it just shouldn't be as prominent as a pop-up notification. You should still make a flash animation on the target icon to indicate the job completion. This is not bothersome, it's a basic action-reaction behavior. > > Use case of this: sending a picture over bluetooth from our mobile to > our superb laptop. The user accepts the file transfer. As it's a small > picture, and the phone is 10cm away from the laptop, the transfer is > nearly instantaneous. No progress dialog is shown. However, the user > still wants to be able to know when the transfer has been completed, > and to be able to access to the received file, but the "finished" > notification never comes. > There should be two different notifications: one small feedback when the transfer lasts a few seconds and the user's attention is still on the task, and one prominent "Finished task" message if the user had time to change tasks and might be attending anything else. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Ideas/Mockups for Mobile System Tray (GSoC)
On 4 April 2010 20:53, Chani wrote: > On April 4, 2010 05:25:22 Yuen Hoe Lim wrote: > > Would greatly appreciate some feedback and comments on my ideas, as well > as > > on the proposal as a whole in case I'm missing something in there :) > > as for more computer-like devices... > I like the way the n900 does IM notifications - the little tiny bubble in > the > corner that has just a few words in it. > > I'm not sure about the "mode" thing, though. > I mean, even if I'm using it like a computer, when a phone call comes in it > needs to be answered or dismissed right away, I can't just go check on it a > minute later. so maybe the intrusiveness of the notification has more to do > with the application it's coming from than what the device in general was > designed for. > > There's an interesting article that provides a solution to the problem of intrusive notifications: growing pop-ups. "Reducing the Cost of Interruption Using Gradual Awareness Notifications" http://groups.csail.mit.edu/lapis/projects/slowgrowth/slow-growth-technote.pdf (short version) http://groups.csail.mit.edu/uid/projects/slowgrowth/gradual-awareness.pdf (longer article) You might want to experiment with this idea. Gradual growing notifications only interrupt the user's conscious flow at natural task breaks, when the user is ready to process the notification. The article shows evidence that this technique is less intrusive than pop-ups: in the experiment, users tended to be interrupted by the notification mainly when finished typing words, instead of while typing (as pop-up notifications did). It has some advantages over other techniques for notification typically used in the system tray: - it doesn't depend on color, so it works for accessibility - it is not a flashy but a subtle effect - the growing speed can be used to signal the relative importance of the notification (fast growing alerts take less time to be noticed). - semantic zooming provides progressively more information: just icons when the notification is small, more text as the panel grows. Maybe you could use this kind of growing animation for bubbles, and try it on some test users? I for one would prefer this style to the popups in the N800/N900. I hate having one of those interrupting my reading every minute when I am low on battery. Having a subtler animation would be better for me. Diego Moya ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Generalizing interfaces and interaction with QGraphicsItems across form-factor boundaries
On 17 August 2010 13:21, Marco Martin wrote: > On Monday 16 August 2010, Stefan Majewsky wrote: > > The reason why I'm writing this is because I started work on libkgame, a > > collection of libraries which shall, at some point, supersede libkdegames > > which is currently used by most games in the kdegames module. In the > > beginnings of the design process, I've identified as a main weakness of > our > > applications the fact that they are designed for mouse and keyboard > > interaction and for desktop form factors. They do not scale to the mobile > > form-factors which are becoming increasingly important in casual gaming. > > > This effort should also cover input methods, in order > > to make it dead-easy to integrate multitouch support in existing > > applications. > > for input, basically if you are chained to single touch, mouse events are > usually mostly good enough, if you want to react to multi touch you should > implement -also- TouchEvents, that have a semantics almost identical to > mouse > events, apart that they have an arbitrary number of points in a single > event. > there are also higher level gestures, but are probably -too- high level to > be > used in games... > The problem with mouse events is that they were created for point-and-click applications in desktop environments, and they don't always translate well to mobile devices. Events like on-hover or keypress are quite difficult to reproduce in touch screens. Games aggravate this problem, as they can introduce a wide variety of interactions. Have also in mind that other non-standard input devices will likely become more popular, such as accelerometers, pressure and proximity sensors, or position tracking (now found at the Wii, Microsoft Natal and PS3 Move). These will be frequently used in casual games as they get added to mobile devices, and open games would greatly benefit from a library providing a standardized way to access them. For low level interaction that supports all those devices, I'd recommend basing the APIs on the concept of crossing-based interfaces[1] which have been poorly supported in traditional widget toolkits, but which I think would make a good basis for touch and position-based interfaces. A cross-based interface keeps track not just of the pointed object, but also which lines are being crossed by the input gesture. Imagine what a game could do if, instead of a mouse-out event, it received an event saying "the pointer has exited the button with direction 38º NorthEast and at a speed of 20 in/s". In my opinion, this mid-level API would make it easier to program games tailored to several different input/output methods. * [1] http://en.wikipedia.org/wiki/Crossing-based_interface ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: multi-screen management
On 18 August 2010 08:42, Chani wrote:
> so... we had planned to have a little tool for managing the containments of
> multiple screens, in 4.5 - but there wasn't time. multiscreen has
> improvements, but also regressions - well, *a* regression - you can't
> access
> the containment of a screen that's not plugged in. the same applies to the
> per-desktop view stuff (they have a lot in common).
>
> anyways, jpwhiting said he might be willing to implement such a tool, and
> yesterday I was inspired (compelled?) and found myself writing about how
> such
> a tool may look and act: http://community.kde.org/Plasma/Multiscreen
>
> feedback would be very welcome. :) and since I know many of us hate
> clicking
> links, here's the current text copy&pasted:
>
> Plasma/Multiscreen
>
> With the death of the ZUI, managing multiple screens (or per-desktop views)
> becomes... a little trickier. A UI for managing the containments ("widget
> groups" in user-speak?) is needed.
> Contents
> [hide]
> 1 Manager Tool
> 1.1 UI
> 1.2 Under the Hood
> 2 Inactive Screens
> [edit]Manager Tool
> [edit]UI
>
> I have a few ideas here, and would like feedback.
>
> The general concept I've got is a grid of containments, with screens left
> to
> right and (if PVD was ever enabled) desktops going top to bottom. If panels
> are to be managed here too, they could be along the edges of the cells.
> Only
> the current activity's containments would be used (no hypercubes plskthx).
> There would be a visible difference between the rectangle of active views
> and
> the inactive 'outside' ones. Containments could be dragged to other cells
> (causing a swap with the containment they're dropped on) and ones outside
> the
> active area could be deleted. Desktop containments would not be draggable
> to
> empty cells, because that could leave a view without a containment (panels,
> on
> the other hand, might have less restrictions).
>
> Usual case mockup http://chani.ca/images/screenmanager-bestcase.png
> Bad case mockup (it could be worse...)
> http://chani.ca/images/screenmanager-worstcase.png
>
> The UI ought to be something a user only needs occasionally, but it should
> still be easy to use.
>
> I considered doing just screens or just desktops, and trying to follow the
> geometry those are displayed in in other places (pager, krandr) but when
> you
> consider there will likely be leftover containments from old screenns and
> desktops that gets awkward.
>
> On the other hand, if there are both panels and PVD, that's also awkward:
> would users understand that even if panels only appeared and were draggable
> within the first row, that they still show up on all desktops? perhaps
> panels
> could have their own special row in that case..?
>
> Another tricky issue: how to represent the containments? If someone can get
> thumbnails of containments working properly I will give them lots of beer
> and
> hugs. :) Im the meantime... well, a grid of identical icons isn't very
> useful.
> there probably ought to be something thing-like for the dragging... I'm not
> sure how much trouble the user will have remembering which containment they
> left where. if fact, if they drag one icon to another identical icon, what
> is
> there to tell them the two containments were swapped at all?
>
> I think that, assuming there are no thumbnails, live previews will be
> important. The user will end up dragging an inactive containment to their
> current screen/desktop just to remind themselves what containment it was.
> If
> they have to hit apply every time that could get rather tedious.
>
> On the other hand, it might be good to keep in mind that the *normal* case
> is
> for a user to have PDV off, disconnect their one external monitor, and then
> want to go check on a widget it had - or swap its containment over to the
> remaining screen if they don't like which one their driver thinks belongs
> there.
>
> The (hopefully) less common, icky case is someone who has multiple screens
> and
> lots of desktops, then turned on PVD and wants to purge all the old
> containments (even though they ideally would be mere config data, not
> actually
> *running*).
>
> Oh, and as for where to go to open this UI: well, it has to run in-process,
> but it's not common enough to warrant a toolbox entry, so I had a crazy
> idea:
> what if whatever kcm is relevant to this stuff (plasma settings + wherever
> the
> PDV setting lives?) had a button that sent a dbus signal to plasma-desktop
> to
> show the UI?
>
> TODO: clean up the above rambling into a more structured document. :)
>
> [edit]Under the Hood
>
> The UI would have to talk to plasma-desktop's current Activity (you can get
> them via DesktopCorona), to ensure that the containment swaps happen
> smoothly.
> Also because one or both containments involved may not be running, once
> that
> stuff's implemented, so swapContainment might not be doable at all :)
>
> [edit]Inactive Screens
>
> When a screen is disconnected (or in PDV, a des
Re: multi-screen management
On 18 August 2010 08:42, Chani wrote: > > Another tricky issue: how to represent the containments? If someone can get > thumbnails of containments working properly I will give them lots of beer > and > hugs. :) Im the meantime... well, a grid of identical icons isn't very > useful. > there probably ought to be something thing-like for the dragging... I'm not > sure how much trouble the user will have remembering which containment they > left where. if fact, if they drag one icon to another identical icon, what > is > there to tell them the two containments were swapped at all? > For want of a (thumb)nail... you could identify containments by showing the list of icons of the widgets included in it. A containment would be uniquely identified by the list of elements it contains. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Why rotate widgets?
On 7 September 2010 13:13, Anne-Marie Mahfouf wrote: > Most Picture Frame users have several such applets on their desktop and > rotate > them to get a visually improved desktop. The Picture Frame applet is > probably > the strongest use case in rotating widgets. > I don't imagine using it without the rotation. > There are people reporting that this feature creates clutter and confusion, for little proven benefit. If the Picture Frame does take advantage of this feature, then keep it to this applet and remove it from the rest. Better yet, create a dedicated interface (a special containment, or a mode to show it only when changing Preferences) to configure it when it's needed, and get rid of it when it's not. In addition to manual direct configuration, this could also allow for some automated effects (for example create a random rotation for all pictures, or auto-rotate widgets to match acceleration sensors) that many people would benefit from without spending much time tweaking their desktop. > > When did we state we would give up on some options? > > I think he refers to people like Aaron saying that KDE 4 would avoid micro-management preferences that choose between two equally problematic interfaces, trying to stick to one good design that works from the beginning. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Why rotate widgets?
On 7 September 2010 14:33, Asraniel wrote: > Appart from the wrongly choosen icon (which looks like a refresh button), i > really can't see any problem with that feature. > Don't let us go the gnome way and delete every feature that not at least > 100% > of the people use. > I don't think we're talking removing this feature. Me, I was suggesting creating a better, more flexible interface for it. On 7 September 2010 15:07, nuno pinheiro wrote: > On Tuesday 07 September 2010 13:48:53 Markus Slopianka wrote: > > On Tuesday 07 September 2010 12:11:52 nuno pinheiro wrote: > > > does it create visual cluter? no.. > > Sure it does. > NO IT dosent, puting my designers hat. that tollbar is not clutered, > minimalist as i like to be but to much empty space is also bad. that > toolbar > is clean and as just about the correct amount of butons. > > You must have a really big screen, or never use small widgets at all. The buttons in the toolbar get in the way when trying to drag the widget; one must carefully search for an empty place in the bar to drag. Every additional button reduces the size of the dragging area for my primary interaction with widgets, which is moving them to a different place. Good design implies that less-used features are made less pronounced. I for one find the whole widget toolbar too intrusive. I put my widgets side-by-side on the desktop, and during normal use the toolbar on one widget will overlap the one besides it, obscuring its contents. I would be happier if the toolbar would only show on demand by clicking a toggle button (a cashew?), not by hovering over the widget. YMMV anyway, different users have different needs. My point is that giving prominent place to rarely used features *does* get in the way and is disturbing for someone. Note that I'm not asking for it to be changed (dashboards in general are of little use for me), I just want to illustrate how it can be a real problem for some people, that should not be hand-waved away. I suppose the definition of "clutter" and "what gets in the way" is personal. I can only think of two ways to prioritize placement of features in the interface, for an open project like KDE: - what developers feel is right for their personal use, or - the expected frequency of use for that feature. > > > on the plus side its a good marketing tool- see i can rotate the > > > clock > > > > > > :) do that in windows will you... > > >Reply: > >shrug "Why would I want to rotate a clock?" > > Why woud i want to play tictack toe? Why woud i want place my windows in > difrent positions? Why woud i want this or that. > So why don't we place a tic tac toe game on the default desktop configuration? ;-) That's right, it would not be used most of the time, by most users. On 7 September 2010 17:12, Aaron J. Seigo wrote: > On Tuesday, September 7, 2010, Markus Slopianka wrote: > > > Isn't this one of those micro-options we once stated to get rid of? > > no. it's a fairly commonly used feature and doesn't get in the way of other > items nor other code paths. > > > I agree that this feature is not one of those micro-configurations that plagued previous iterations of KDE. Still, I fail to see the need to have it always on, always available. Do people really move and rotate their widgets, with the same frequency that they interact with their contents? As far as I can see, none of the use cases presented in this thread would be hurt by a "configuration only mode", while it does get in the way for some of us in its current form. What was the original reasoning in having the complete direct-manipulation interface for plasmoid applets always present? Is it for the kool effect? To make it discoverable? Or is there a benefit in having the toolbar always available that I'm missing? ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: [kde-promo] start of elevator pitch for plasma on devices
In the elevator pitch I miss some mention to the existing support behind the Plasma platform. Something along the lines of "In addition to the community work, Plasma development is supported by $BIG_COMPANY_NAME", where $BIG_COMPANY_NAME currently could use the names of Nokia, Intel, AMD... for MeeGo, or some others that support KDE in general. On 19 November 2010 11:05, Aaron J. Seigo wrote: > On Friday, November 19, 2010, Marco Martin wrote: > > another thing i would like to add, maybe as a separate page is a set > > of counterpoints on the most common objections i heard, like > > why not using just qml a big case of platform vs primitive ui toolset > > why what various kde ieces offers is not all hoverhead (i've heard > > many people screaming about duplication of stuff that we offer. is not > > as much as it seems i think) > > as you hear these, please add these questions and objections to the bottom > of > the page under the misc notes section. i'll try to work through them as i > can, > unless someone beats me to it of course. > > i'll still work on the opening arguments for a bit, but then we definitely > do > need to have answers for the common / innevitable follow up questions that > occur. > > > will look at it, however help of somebody not too tied on the > > implementation details would be helpful :D > > yep; which is why we have the promo people on the thread. already getting > some > good feedback from them :) > > -- > Aaron J. Seigo > humru othro a kohnu se > GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 > > KDE core developer sponsored by Qt Development Frameworks > > ___ > Plasma-devel mailing list > Plasma-devel@kde.org > https://mail.kde.org/mailman/listinfo/plasma-devel > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Reworking the kwin tabbox
2009/7/16 Martin Gräßlin : > My idea is that with alt+tab it should work as ever known. But that it is not > required to keep alt pressed (keeping it pressed shouldn't harm). There's a way to achieve that goal without breaking the normal alt+tab quasimode behavior. Hold alt + tab as many times as required + release tab = change window (same behavior) Hold alt + tab + press cursor key + release tab = make tabbox persistent. From now on, pressing tab or cursor arrows navigates the window list normally, and Enter is required to close the tabbox and open the selected window. You can add as many extra keys as desired after the initia alt+tab, to free the quasimode and "trap" the window for providing additional functions. For example, hold alt + tab + s + release tab, could activate a "search" function among the name (or content!) of the open windows. Or: hold alt + tab + k + release tab, could be used as the trigger key for the krunner-like extra functions. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: notifications, again :D
Arriving late to the discussion, so just my 2 cents: 2010/1/26 Aaron J. Seigo : > On January 26, 2010, Ivan Čukić wrote: >> On Tuesday, 26. January 2010. 11.57.36 Riccardo Iaconelli wrote: >> > On Monday 25 January 2010 13:20:56 Marco Martin wrote: >> > > opinions? comments? >> > > would like to hear some feedback before implementing anything since >> > > each solution would lead to a different total screwing of the current >> > > implementation :p >> >> What about having something like Facebook does - one small notification >> popup at a time, and when the user clicks the 'show notifications' he/she >> gets the list of notifications. >> >> We don't need to go for the list as well, but since the user clicked the >> 'show notifications' button we don't have the problem of contextual >> information covering a large part of the screen - it is what the user >> wanted. > > the problem is when we have 10 notifications from one app and 1 from another > plus a few running jobs. There's an easy solution for that: group notifications by application when showing them for the first time. Say you have Kopete throw in 5 notifications, then the important Low Battery shows, then Kopete rapid-fire 20 notifications more. Final result? Two alerts on screen, on of them is Low Battery - the other is a pile of 20 Kopete notes, latest on top. This solves the problem of bad-behaved applications, they will not spam the screen even when they are the only player in town. When you really want to see what it had to say, you can expand that pile of 25 notes (and maybe even regroup them later). Simpler than a priority scheduler, ain't it? Maybe you could even explain to Aunt Tillie how it works! ;-) 2010/1/26 J Janz wrote: > Having notifications queued (by showing just 1 at a time) seems like a good > idea to clean up the desktop but it could bring more trouble than just that > inconvenience. > 2010/1/26 Marco Martin: >> if the mouse is already somewhere over a notification any new notification >> should be queued and not displayed until the mouse leaves > > Yeah but, see, if you have one notification at a time, this totally ruins > the purpose of battery (or whatever else)'s urgency on telling you your > power is going away. If the mouse is over a notification, we can safely assume the user is paying attention to notifications. Having the user attention makes many notifications turn from "clutter" to "information". So the original motivation for limiting the number of shown alerts is not present while the user is reading them - additional alert groups could be shown in that case, but be limited to one (or two, or three) group otherwise. This has the benefit over a "show me everything" persistent state that it only fills the screen when the user is looking for it, avoiding the "kopete noise in the backgroung". It's true that when the mouse is over a notification it should NEVER, EVER change to a different one (that's an important thing, guys!) but the solution is not hiding new information, is placing it somewhere else. In the example, say I get a new mail notification. I hover the mouse over it to read the mail's subject, and the battery notification runs. What's the best thing to do? Not to hide my mail note, not to hide the low battery note. Guess it? Just show the new battery alert below (or above) the user-selected mail alert! ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: notifications, again :D
2010/1/26 Aaron J. Seigo wrote: > On January 26, 2010, Diego Moya wrote: > for when the user specifically calls up the notifications (e.g. by expanding > the popup or by clicking on the (i) icon), this will be great. > > for notifications that are auto-popped, it suffers from the issue of showing > all existing notifications when really only the latest one is relevant. > Why do you assume the latest is the relevant one? In the example that isn't true - the most important was the Low Battery, which is not the last. >> Simpler than a priority scheduler, ain't it? > > my proposal didn't actually have a priority scheduler in it other than > "critical notifications should get precedence", which is likely needed no > matter what we do (stacking vs queueing). OK, establishing priorities would help in having the Low Battery warning noticed instead of the Kopete ones. But then you need to find a way to inform the user there are new warnings available, even if they are being queued until you dismiss the important one. And there's also the need to support a use case to which I don't know whether you're paying enough attention: the "away from keyboard". The user should be able to go for a walk, or talk to a person besides her for some minutes without looking at the screen, and later tell if new unseen messages have appeared while away. So what do you think of the following flow, which tries to take the best parts of the previous suggestions in this thread? - As soon as a notification arrives, show a popup for it. Group several alerts from the same application, to keep badly behaved apps in check; every time a second message arrives from the same app already shown, make a "one-second yellow flash" animation to show that it has been updated, and replace the old content with the new one. - Have each popup disappear after a few seconds, on a FIFO basis (each popup having its own timer). Every time one is hidden, do a flashing animation of the (i) icon to show where it went. This solves the problem of "I think the current job has finished because the popup went away". Grouping by application and hiding after some seconds would prevent the screen being littered with alerts. It's still theoretically possible to have the screen covered with warnings, but this would only happen if many applications show alerts at the same time - and this is a valid reason to show all them at once, since they are generating a lot of background activity that could degrade performance or be a symptom of a system problem. - The first time a popup disappears, the (i) icon activates into a subtle spinning or fading animation, to show that there are recent notifications on which the user has not acknowledged their existence (she might have missed them). The animation will only stop when the user clicks on the (i). This is how the user confirms that she has seen everything which has been briefly shown in the transient popups. - Clicking on the (i) once shows a panel with a scrollable list shows all notifications in the current session (or the current day, whatever lasts longer), ordered by time, latest on top. Notifications will not be grouped by application here. This allows the user to review everything notified recently, and to stop reading as soon as she recognizes already viewed notices (i.e. a familiar "blog" model). Running jobs would keep flowing to the top of this panel as they are always the latest notification, because they're working (and thus adding new data) right now. As they come to an end, they will get placed relative to other notes at the precise moment they finished. New alerts arrived while the user is reviewing the panel would be placed at the top, outside the scrolling panel, and would also disappear after a few seconds to be placed at the top of the "blog". The list could be optionally ordered by alert priority, if notification priorities get implemented. This would make easier looking for "all important notifications in the current session". - Double-clicking the (i) stops the animaiton without showing the panel (same effect than clicking once, viewing the panel, and clicking a second time to close it). In summary, you have two simple related ways to show notifications: - a temporary sequential list showing new messages (and only them), that doesn't require any user interaction. It doesn't use much screen real estate because of grouping and auto-hiding. - a (semi)persistent sequential list that only requires user interaction to dismiss a "new messages available" subtle animation, and that allows reviewing older messages (either already seen or not). It doesn't require much screen real state because of the scroll list, and it's hidden when the user finishes using it (but can be retrieved any number of times). ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: notifications, again :D
I've prepared a storyboard with my concept for notification popups (explained in my previous post): http://megaswf.com/view/c72134c5318f9aee8cfe2b3a99c3fa0a.html I've changed my original "group" idea to a "pile": several popups get visibly piled at the same place. This doesn't take much space, and still shows how many simultaneous alerts arrive. 2010/1/27 Aaron J. Seigo wrote: > On January 26, 2010, Diego Moya wrote: >> 2010/1/26 Aaron J. Seigo wrote: > what i said is that showing all the previous notifications and jobs when a new > notification is shown in the automatic popup is not desirable. Yes, I agree with that. My idea was not to show all previous notifications but just the new ones as soon as they arrive. Thus each alert would create a popup exactly once, right when it's created, and never again. > when clicking the (i) icon, i'd like to be able to see the last active > notification of each application. e.g. if kopete and kontact have both sent I'd like to see the last active notification of each application even if I don't click the (i) icon. This is the best way to know that there's a Low Battery warning even if Kopete has sent a message one milisecond later. Showing only one message a time, if the two messages are together or I'm not looking when the first one appears, I would never notice there have been two alerts instead of one - so I wouldn't know to click the (i) icon. > out a notification to me, i should be able to see both if i purposefully click > the (i). however, if kopete has sent 10 notifications, i should probably only > see the most recent one, and be able to scroll through the older ones. How long would you keep older warnings, and how would you layout them? Say 20 applications have sent several messages each in the last hour. Should the (i) icon show 20 boxes with 20 scrollbars? >> recognizes already viewed notices (i.e. a familiar "blog" model). > which seems backwards: if i explicitly ask for the notification to be shown, > i'd like to be saved digging through all the kopete notifications just to find > the last appointment notification from kontact. Fair enough. I'm trying to prevent the user from missing any one alert, which could happen if the same application sends two notifications together. I think that putting together several fast messages sent from the same application, should be handled by the notification system, not left to individual applications like Kopete. > this forces user interaction; notifications are often passive. simply showing > a number and activating the (i) should be enough, as we currently do. Ok, as long as the number is reset to 0 after the user clicks the (i). I haven't looked if this is what happens now (and I'm now away from home so I can't check). ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: notifications, again :D
2010/1/27 Marco Martin wrote: > the thing i did start to implement was funningly enough almost the same, only Proof that local optima do exist for good designs, given the same constraints! :-) > thing, i still think the new ones should be piled in front of old ones, not > behind In what order do you remove them? Piling new ones at the back allows for alerts to be seen in arrival order. Piling them on the top creates a FIFO stack, which I'm not sure how to clear up - much less automatically with timers. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: notifications, again :D
2010/1/27 Marco Martin wrote: > the policy should be this: > - if a new one arrives check if there is already a notification of the same > app if it is remove that one What if I didn't have time to read that one, because it got instantly covered by a newer one? Then I'm forced to open (i) to review what was discarded. > - else remove the oldest Same thing. With "pile on top" I have no guarantee to have seen previous messages, they could have been covered too fast or I might have been looking elsewhere when they appeared. > -put the newest notification on top > > old one wouldn't be "lost since the stack will be positioned to be enough to > show the titles of old ones So this policy is "see the whole of the last message in a burst, see only the headers of previous ones". I think this will work in a burst from the same app, but will favor noisy applications over quiet ones. That important "Low battery" alert would quickly be covered by Kopete messages. Are you sure you can put up with this? At least, putting new messages behind gives all applications equal chance. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: notifications, again :D
2010/1/27 Marco Martin wrote: > On Wednesday 27 January 2010, Diego Moya wrote: > since given how i want to implement it one behaviour or the other would mean > basically an one liner difference, we will be able to test both for a wile and > see what seems better Seems reasonable. I'm sure someone in the future will ask to make it an option! ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: notifications, again :D
On 1 February 2010 14:41, Marco Martin wrote: > for all who can't try trunk, a screencast of the current status is there: > http://www.notmart.org/index.php/Software/The_future_of_notifications Great work! Is there a way to show the beginning of the message body for the popups that are partially hidden, as a teaser for the full message? Like this: Kmail -> Error while checking account diau...@libero for... X Kmail -> Error while checking account m4...@libero for n... X Kopete Messenger -> Incoming message from account prova ... X ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: notifications, again :D
Also, maybe the progress bar for running jobs could be placed *below* the popups and NotificationScroller, instead of above. This way they wouldn't jump up and down like that. (I know, I know it was my idea putting them on top)... On 1 February 2010 14:59, Diego Moya wrote: > On 1 February 2010 14:41, Marco Martin wrote: >> for all who can't try trunk, a screencast of the current status is there: >> http://www.notmart.org/index.php/Software/The_future_of_notifications > > Great work! > > Is there a way to show the beginning of the message body for the > popups that are partially hidden, as a teaser for the full message? > Like this: > > Kmail -> Error while checking account diau...@libero for... X > Kmail -> Error while checking account m4...@libero for n... X > Kopete Messenger -> Incoming message from account prova ... X > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: activities
Short reply: Move activities to the third dimension - they should be a generalization of the plasma dashboard to N layers. Open windows should adapt to the current selected layer (dashboard = all windows autohide; other layers = show new background + show attached plasmoids + change Nepomuk-enabled parts in applications) Long reply: On 5 February 2010 01:54, Chani wrote: > One thing that is *very* important to me is that people must be able to > understand activities enough to use them. A lot of people really don't get > virtual desktops. I don't want to hold back those of us who do, but neither do > i want to make a complex beast that scares off all but the geeks. The current problem with VDs and activities is, they are conflicting spatial metaphors. They both are using the plane surface in two different inconsistent ways. If I'm working with a set of windows and go to the right (either with the "rotating cube" or "viewport horizontal shift" effect), it will change windows as I enter in a new virtual desktop. But if I zoom out and zoom in to the right of the initial workspace, it will change activity instead - same windows but different background. See how it doesn't make sense? The zooming interface is not the one to blame for confusion - several popular implementations (the iPhone, for example) show that the general public is not confused by it. But the same relative movement arriving to different places? That's a no-no. We should decide which service (VDs or activities) keeps the plane metaphor, and move the other competing service to use a different one. I first supported merging "virtual desktop" and "activity" in a 1:1 relation, but this can be too limiting - and I think I have now a better idea. On 5 February 2010 10:43, Marco Martin wrote: > there were so much ideas in the past, > - a desktop grid like, did with or without virtual desktops: problem of > windows not showing their real content and other virtual desktop limitations. > also been pointed out that this approach is inherently modal. is a problem? > maybe not since if i want to change what i'm doing is a modal action per se. > > - a strip that looks like the widget explorer, not modal and we don't have > virtual desktop problems. thumbnails becomes very little however and is an > advantage because one can not worry about wrong contents anymore, but a > disadvantage because they're so little that they could become almost > meaningless (they should just show the containment probably, and different > wallpaper for each contaiment shoud be almost enforced) None of these solve the conflict bewteen the two usages of the plane. How do you explain to the user where windows go when you switch virtual desktops? > > - or we could go barebone, just text, with an activitybar, a popup menu, a > secondary taskbar, whatever. it will probably be the first prototype anyways > and could be the "faster" to use in the end, but it will have a big problem of > learnability.. This *would* solve the problem, as it removes any physical metaphor for the activities. But it makes them abstract, again. What I think should be done is moving the activities to the Z axis. This is a proven metaphor - windows already behave this way (a window is the 70's portrayal of an activity - a set of tools designed to work together). Since activities have a strong linkage to the desktop, I suggest a metaphor of activities as a pile of desktops along the 3rd dimension, one of top of the other. How does this solve the conflict between desktops and activities? The VDs can keep the horizontal plane layout, being a big table with boxes in a grid - each box having a different group of windows. Camera panning = switching VDs. Activities then can be like the tablecloth on the table. We have several layered tablecloths, and we can change the extended tablecloth to support one activity or the other. The transition effect could be a movement in depth, like a tickler file or a Rolodex. This is compatible with whatever spatial effect used for the VD change (cube, infinite strip, big plane), as activities would be layers parallel to the VD plane. You could use the opposite change instead and put activities in the plane while virtual desktops are layers parallel to the activity desktop. I don't mind, except that the plane has been used as the standard metaphor for VDs for many years now. Now go and make the different code snippets match to the chosen metaphor. ;-) ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
