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
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
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
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
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
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
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
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
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
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