openSUSE UX May 2007

ux@lists.opensuse.org

26 participants
15 discussions

Re: [Fwd: [opensuse-ux] UI redesign - AppArmor reporting]

by Martin Schmidkunz

Hi, > I'm looking for suggestions and feedback about the apparmor reporting > UI. The plan is to completely redo the report > scheduling form (the "start" page of the reporting module). That sounds like a cool idea! I think that for doing proper suggestions for redesigning the apparmor reporting module one of us within the UX-team needs the time, to understand the functions of the current module. I will ask for resources on our next team meeting on Wednesday evening (CET time) and let you know afterwards. Cu, Martin -- Martin Schmidkunz User Experience Specialist martin.schmidkunz(a)novell.com +49 (0) 911 740 53-346 ------------------------------------- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) ------------------------------------- Novell, Inc. SUSE® Linux Enterprise 10 Your Linux is ready http://www.novell.com/linux -- To unsubscribe, e-mail: opensuse-ux+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-ux+help(a)opensuse.org

14 years, 12 months

syntax versus semantics in UI

by Johannes Meixner

Hello, I have a general question if there exist solutions how to show semantics regarding user input via UI. I know how to show syntax regarding user input via UI, e.g.: - show several checkboxes for several binary (on/off) values which can be set "on" or "off" independent of each other - show radio buttons for several binary (on/off) values where only one of them can be "on" - show a list of predefined values if only this values are correct input - show a text input field for an arbitrary input value I don't know how to show semantics regarding user input via UI. Example: a) for one kind of input values the user is free to choose what he likes because any choice would work b) for other kind of input values the user is not free to choose what he likes because only the right choice would work Is there a solution how to show this kind of semantics regarding user input via the UI? Simple real-world examples are: 1) Password input: A password is an arbitrary input value so that a text input field is shown in the UI. But the semantics is different if - a new password is to be set => case a) above - the system asks the user for his password => case b) above 2) Printer specific option settings: Specify the printing resolution versus specify the media size: Both values can be choosen from a list of possible values e.g. Resolution: 300dpi, 600dpi, 1200dpi (the supported resolutions of the printer driver) Media Size: A4, A5, Letter, Legal (the supported media sizes of the printer driver) The syntax is the same for resolution and media size but the semantics is different because - any choice of the resolution works => case a) above - only the media size which is actually in the printer works => case b) above You might think that this is no UX/UI problem at all because it is obvious for any normal user if the semantics is of type a) or b). This is true for my simple examples above but in general it isn't, see this snippet from a mail: -------------------------------------------------------------- > > Why did you acitvate the filtering when you want to set up > > a raw queue? Filtering is exactly the opposite of "raw". ... > Reading this setting in the YAST module, I thought it was > more a choice: do you want the filtering done on the > server side or on the client side. It is a choice but it is not a choice where you are free to select whatever you like - it is a choice where you must choose the right setting which works in your particular environment. -------------------------------------------------------------- In the YaST printer config we have two checkboxes [ ] Share Printer [ ] Do Local Filtering where the first one is of type a) but the second one is type b) but there is nothing in the UI which indicates this difference and this difference is no longer obvious to any normal user. Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany AG Nuernberg, HRB 16746, GF: Markus Rex -- To unsubscribe, e-mail: opensuse-ux+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-ux+help(a)opensuse.org

14 years, 12 months

Request for icons for updater applet

by Joerg Kress

Hello everyone! NOTE: Cross-posted as this involves both teams, IMHO. We have a need for icons for the updater applet for both GNOME and KDE. The current icons have certain limitations in areas of usability and accessibility. Please refer to bug 246157 [1] for an example. I have made some proposals in the wiki [2]. One might also check the parent page [3], which also holds the current icons. Currently we have 4 icons, based on a blue dot with a small label on the bottom right. Each label indicates a certain state: * Red: Error occured * Yellow: Updates available * Striped(Yellow/Black): Checking for Updates * Green: No updates We want to have another state: "Applying Updates", which could be merged with "Checking for updates" into "Updater working/Busy" So, UX teams should verify which states need distinguishing from a usability perspective and artworkers should then find a usable and accessible solution. Links: [1]: https://bugzilla.novell.com/show_bug.cgi?id=246157 [2]: http://en.opensuse.org/Updater_applet/Icon_proposals [3]: http://en.opensuse.org/Updater_Applet Thanks in advance! Josh -- Jörg Kreß <jkress(a)suse.de> YaST2 Development _________________________________________________________________ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-ux+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-ux+help(a)opensuse.org

14 years, 12 months

UI redesign - AppArmor reporting

by David Drewelow

Hi, I'm looking for suggestions and feedback about the apparmor reporting UI. The plan is to completely redo the report scheduling form (the "start" page of the reporting module). Some other reporting forms will get minor changes, mostly to fix yast style bugs. It was suggested that I model the form after the new tabbed printer configuation form, and I'll be adding a mockup for that soon. This link shows the currently used forms, and some ideas for the new scheduling form. The new work is near the bottom (Report Scheduling Redesign). http://en.opensuse.org/YaST/AppArmor/UI-Redesign Thanks, -David -- To unsubscribe, e-mail: opensuse-ux+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-ux+help(a)opensuse.org

14 years, 12 months

Re: [opensuse-ux] Installer UX Ideas.

by Brian Imhausen

If we transition to a "live" installation, could we give the option for desktop environment at boot (or soon thereafter) and give the user the option of running either of the desktops live? That way, they can play with either one without installing it to their machine and if they don't like the one they chose, they can reboot and try the other... this is assuming there is space on the installer cd/dvd for both pieces of software. Maybe distinct desktop installer cd images (a la Mandriva) and a unified dvd image which presents the user with an option before running the live environment? The description of each desktop's functionality could appear on a page for downloading the installer media... could the installer then be made to only offer the user a choice of desktop (along with appropriate descriptions) if more than one environment is available on the source media? Brian "Multiple graphical desktop environments are available for Linux - KDE and GNOME are the most popular. openSUSE offers a choice of both. Both will cover your basic needs. Which one suits you best is a matter of personal taste and wants." -- To unsubscribe, e-mail: opensuse-ux+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-ux+help(a)opensuse.org

14 years, 12 months

partitioner

by Martin Schmidkunz

Hi, after agreeing with you many times, that our partitioning module needs some facelift, I have created some mockups how this could look like: http://en.opensuse.org/UX/Partitioner The module would be divided into two tabs: * basic partitioning * Logical Volumes (maybe Logical Volumes Management (LVM) would be more appropriate) The "basic partitioning" tab provides: * An overview table with informations about hard discs and their partitions (as far as I understood Ihno there are plans to exchange the device names (hda, hdb) with the device ID, so I try to do this already in this mockup) * search for hard discs (might be cool for environments with lots of hard discs) * filter to display e.g. only active hard discs * an action area in the second half of the module where the user can work on the partitions without having to click an extra add/edit/delete button; the current mock-up shows the action area when the user clicks on an unallocated disc space. I thought about displaing a graphical overview, but I rejected that idea for the following reasons: * no additional information to the table overview * might be suitable for desktop environments but not in an environment where there are many partitions to manage which can be formated with many different file systems * the target audience (sys admins) prefer numbers to graphics * useless in textmode * needs quite a lot of space I think, that most of the mock-up should be instantly clear, I just want to mention some points: * hdd activation: to activate a hdd the user has to display an deactivated device and then mark the check box in the overview * partitioning schemes: came up in a discussion and should ease the deployment of partitions for ** unexperienced users as they can choose from different schemes (e.g. 3 linux partitions with equal size) ** experienced users as they don`t have to do the same work over and over again but can customize a scheme and then apply it. * dynamic resizing: came up in a discussion and means: if unallocated disc space is available and the partition is quite full it aquires needed disc space automatically. * Delete partition: the user needs to set the size of the partition on 0 MB. LVM part: * the basic workflow of creating a LV is: ** create a physical volume ** create a volume group ** create a logical volume (linear, stripe, mirroring, snapshot) ** format logical volume ** set mount point ** mount it On the first start of the LVM-tab there will come up a pop-up, which offers the user some help and explanation around the LV topic. This pop-up will have a "don`t show this dialog again"-button. The tab is devided into two sections * physical volumes * logical volumes In each section the user can create/edit/delete the corresponding volume type. Not a killer design, but it seems to me the easiest way to present this topic. So, what do you think? Enjoy, Martin -- Martin Schmidkunz User Experience Specialist martin.schmidkunz(a)novell.com +49 (0) 911 740 53-346 ------------------------------------- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) ------------------------------------- Novell, Inc. SUSE® Linux Enterprise 10 Your Linux is ready http://www.novell.com/linux -- To unsubscribe, e-mail: opensuse-ux+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-ux+help(a)opensuse.org

14 years, 12 months

Installer UX Ideas.

by Jyllian Marie Thibodeau

I was talking with Brian about which information we'd like to collect from the usability tests, and anticipating the various personas that might come to take the test (and, eventually, possibly use the installer). One such persona involves a low-to-medium experience user who is typically a Windows user. This person may or may not have installed Windows or Linux in the past, but is most likely to depend on the system guessing sane defaults, and may hit a usability snag if they don't. This is fine, if the system does indeed guess correctly, the only involvement required (and likely the most complicated interaction they'll faced) from them during the install would probably be from the partitioner (which I know we're working to improve). The Windows installer in particular glosses over the partioning, as its default involves using your whole hard drive as a single partition. I was trying to figure out how to synergize the sort of supportive, generally-non-technical install that this person would need with the sort of hands-on, tiny-detail install that a more advanced user might need or want. One idea for a compromise I came up with would be a screen at the beginning of the install, with a series of checkboxes to choose those components that you wanted to use during the install. These components can range from "Tweak Hardware", or "Install Additional Packages" to "Set Theme" -- and, short of a disaster, only those options which are selected will be presented to the user. For a custom install option, we could even have some of the more likely ones pre-selected." I include "Set Theme", because, particularly for the nontechnical user, customization (which, in my opinion, also includes the smooth installation of additional software via a nice package management system, but this is a different issue) is a big part of what makes them feel like they "own" their system. The sooner a user feels "at home" after an installation, the better. Ideas? -- To unsubscribe, e-mail: opensuse-ux+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-ux+help(a)opensuse.org

15 years

Here to participate & My thoughts

by Mohammad Bhuyan

Rajko & Martin, Thanks for welcoming me. I am here to participate and do my part whatever way I can. I am aware of the ongoing improvement work and I am learning more about them so that I can participate. At this stage I am using OpenSUSE 10.2 on my laptop. My desktop box is going to be 10.2 (which was supposed to be by now :P ). Before opening my mouth I want to see 10.3 (virtualization?) in action so that I know whats the latest state. Should a user expect major changes in desktop experience on 10.3 from 10.2? Software Portal / Application Manager is really a cool concept. Once it works and well integrated into desktop workflow, this is going to remove the major pain of desktop management. I can't wait to see it working. As I said, I am yet to know more to make useful comment. Here are some thoughts that may/may not make sense. As our desktops are more connected than ever, it is a frequent practice of an application to do something over the net and then ask for user notification/intervention. Common example being notifying availability of updates, email etc. And with Googles model of online apps we are yet to see integrated model of desktop/online computing. As a result our system tray/panel is becoming a forest of icons with every application setting-up/registering its own method of doing online services integration. So I was thinking that it could be a good idea to develop an architecture where a single system component (lets call it System Agent) will provide a framework for applications to register it applet modules that will do the application specific online bits. The system agent will be presented in the Desktop UI in a clean and simple manner (a single icon in system tray) and the applications will provide a mostly uniform (yet application specific) event notification / user intervention request to the user. This system will also help the underlying OS to notify / interact to the user. So starting from daemons, kernel modules, email arrival, software update ... any event / notification communicated to user through a defined framework and hence most importantly with a consistent Look & Feel. The initial idea came to my mind as part of the Software Portal / Application Manager concept where I guess there would be an agent in my system which will check & notify me of availability of updates / new arrival. Then I thought why not a generic framework what more apps can use and provide a consistent look & feel. I am not sure if I could explain what I tried to. Please comment so I can clarify. I wanted to add more bits regarding some UI issues. I will take it slow :D. Also I will cover some in my other email in reply to Silviu. Regards, Mohammad -- To unsubscribe, e-mail: opensuse-ux+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-ux+help(a)opensuse.org

15 years

note: gnome main-menu

by Christian Jäger

Hello all, because it touches upon the subject of this ML, I wanted to give a notice that on opensuse-gnome there is a little discussion on usability-enhancement/redesign-proposal for gnome main-menu. Following bug-reports have also been posted: Bug 274817 - revamping the GNOME main menu layout to something simpler (https://bugzilla.novell.com/show_bug.cgi?id=274817) Bug 274852: Merging gnome main menu's 'Documents' and 'Places'-tabs https://bugzilla.novell.com/show_bug.cgi?id=274852 Bug 274868: integrating the application-browser into gnome main-menu https://bugzilla.novell.com/show_bug.cgi?id=274868 Bug 274934: integrating control-center into gnome main menu https://bugzilla.novell.com/show_bug.cgi?id=274934 Thanks for your time. Greets, Chris -- To unsubscribe, e-mail: opensuse-ux+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-ux+help(a)opensuse.org

15 years

"user-experience" - the right perspective

by Mohammad Bhuyan

Hi, It feels good to see how the opensuse community is taking the right perspective on this topic of the usability of OpenSUSE. As a user who is trying to make the switch (not the first time), I will share some of my thoughts about my experience. I am recently trying to make a complete switch to Linux (again and as usual lots of hiccups). Every time I find it making a lots of progress in application stability and GUI capabilities. As I am a software engineer, I am also impressed about seeing the Kernel, X, Desktop Environment etc to morph into systems with designed architecture. I am here not to make complains about buggy codes all around. This is the easy part to fix. I want to emphasize on the part where "Desktop Linux" is just a nightmare compared to "Just Works" Windows. I spent the whole weekend on OpenSuSE Install and "make it work exercises" and at the end it was a broken install beyond fixing (or another few days of community email exchange to fix it). If it were windows I am sure with about 50 clicks, 5-7 list box selection and name/password typing of 30 min I would have had my box ready. Does it make Windows a better OS? NOPE!!. But It is a better "User Product". Why not? It "Just Works". You press button, it flashes a boring logo and then hola ..You with your mouse is ready to rule the world. Adding/Removing apps are AMAZING. Applications have VERY CONSISTENT look. So you most of the time know how to go about using the app and what specific windows/icon/text/menu means even if it is a application that you just installed to check out. You don't need to know about "Dependency" as, if there is something that the app I am trying to run requires then it will be taken care of instead of bothering you. I: May I have some water please? You: This involves a dependency on Mug/Bottle. Do you want to have that too? What the ...??!#!#$? I hope you see what my point is. In my early days of software engineering career, I was lucky to have a CEO who taught me a great deal about the concept "Productization". I came to learn to "code for end user". That's when I gave up showing "Initializing Inter process Communication subsystem ..." message in application startup / splash screen. They never care even if I am sending data to satellites, all they are waiting is for that stupid app UI so that they can start their work. My point being, I see Linux distributions full of amazing apps that are Code developed by programmers for programmers. Also many times the codes are "working code" that are "not productized". For example : Explain me how flashing 20/30 progress bar with downlaoding../parsing... messages help while I am adding installation source. As a engineer I can see clearly its a "developer testing" code that helps to see if download/parsing is going OK. How a end user will benefit from this messages. Also that flashing is annoying enough to nuke the programmers den. I can go all day long pointing out what I think are sins of User Experience commited in App UI, System customization, Desktop workflow, but this email was more about to appreciate the steps taken to focus on the hard part (getting a app that a user will like) than the easy part of writing few 100 lines of code to do something in a annoying way. Regards, Mohammad ------- Mohammad Bhuyan Software Engineer (R&D) -- To unsubscribe, e-mail: opensuse-ux+unsubscribe(a)opensuse.org For additional commands, e-mail: opensuse-ux+help(a)opensuse.org

15 years

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openSUSE UX May 2007