permission-based roles

20 Sep 2004 - 1:03pm
9 years ago
1 reply
421 reads
Jim Hoekema
2004

In theory #1 is better, but how it "plays" depends on how much difference
there is between the levels of permission. I recently worked on an
application with the same problem -- they used "tabs" in a web-based
interface. Problem was, administrators saw 6 "tabs" all filled with
information, while mere "users" saw all 6 but 5 of them were empty! They had
a "tabbed" interface with only one tab that had any content! This seemed
rather irritating, especially when the mere "user" outnumber the
administrators about 100 to 1. The result was an interface optimized for 1%
of the population, leaving an annoying and seemingly "broken" UI for the
99%.

So, I was say it depends on the scale of difference among the function sets,
and among the populations concerned.

- Jim

-----Original Message-----
From:
discuss-interactiondesigners.com-bounces at lists.interactiondesigners.com
[mailto:discuss-interactiondesigners.com-bounces at lists.interactiondesign
ers.com]On Behalf Of conrad_ixdg at spamex.com
Sent: Friday, September 17, 2004 4:25 PM
To: discuss-interactiondesigners.com at lists.interactiondesigners.com
Subject: [ID Discuss] Communicating permission-based roles in the
interface

[Please voluntarily trim replies to include only relevant quoted material.]

(sorry for cross-post)

Please take a moment to vote for one of two "camps" within my design team:

Background:

My team is working on a web-based application that will be used by several
different people, in permission-based "roles", to manage a financial
services account. There will be the "owner" that can do everything, the
"proxy" that can do nearly everything, and a "read-only" role. All of these
roles will be allowed to "see" everything, and they will likely work closely
together in a small-business setting (think: boss/assistant). We're
grappling with how to communicate these levels of permissions in the
interface.

The two camps:

Camp #1: Design a single interface, for all three roles, that communicates
permission levels by "graying out" functions that cannot be performed by a
particular role. This allows the user to know that the function would be
there, but is not available to him/her because of the permission levels set.
If permissions change for that user, the graying-out functions would appear
where they've been all along, thereby limiting the learning curve as the
user takes on a new role or plays multiple roles (their own personal account
vs. company account). The development team would only have to build and
maintain a single application, and the customer service reps would only have
to be trained to support a single interface. The term "graying out" is
being used to illustrate the concept, but this may very well be another
visual treatment.

Camp #2: Graying-out links is confusing, because potentially large parts of
the interface could potentially be seen but not accessible. It would make
more sense to assemble all the functions allowed for a particular role, and
design an interface for each of these roles.

Please send me your opinion - camp 1, camp 2, or other (I'm sure there will
be many), and I'll summarize for the list. Also - if you have any
references that speak to this design, please pass them along!

Many Thanks,

Andrew Conrad
Lead Information Designer, DIGITAS
aconrad at digitas.com

_______________________________________________
Interaction Design Discussion List
discuss at ixdg.org
--
to change your options (unsubscribe or set digest): http://discuss.ixdg.org/
--
Questions: lists at ixdg.org
--
Announcement Online List (discussion list members get announcements already)
http://subscribe-announce.ixdg.org/
--
http://ixdg.org/

Comments

20 Sep 2004 - 1:29pm
Elizabeth Buie
2004

I am amazed to see so many votes for #1, when to me it is entirely
unacceptable.

Graying something out is intended for *temporary* disablement due to
task-related conditions or something else that may change during the
interaction. It indicates that the item will be available *to that user*
if circumstances change. In this case, there is nothing that a user can
do to see the items for which he or she does not have the authorization.
This is of critical importance if the application ever uses the standard
meaning of "grayed out" for items that are unavailable for reasons other
than permissions, in which case "grayed out" would have two different
meanings in the app.

I vote for #3 -- eliminate the following: "All of these roles will be
allowed to "see" everything". Don't show people things that they can't
access.

Your description of the context of work, however, leads me to believe that
it could be useful for everyone to know what others can perform. So I
would suggest devising some means of showing an unavailable option that
looks different from "grayed out." Make these options visually distinct
from both the "available" options and those for which the standard meaning
of "grayed out" (unavailable under the task-related conditions) applies.

I'm not sure I've said this well; I hope my view is understandable.

Elizabeth
--
Elizabeth Buie
Computer Sciences Corporation
Rockville, Maryland, USA
+1.301.921.3326

----------------------------------------------------------------------------------------
This is a PRIVATE message. If you are not the intended recipient, please
delete without copying and kindly advise us by e-mail of the mistake in
delivery. NOTE: Regardless of content, this e-mail shall not operate to
bind CSC to any order or other contract unless pursuant to explicit
written agreement or government initiative expressly permitting the use of
e-mail for such purpose.
----------------------------------------------------------------------------------------

Syndicate content Get the feed