**

Man!

I am sorry I ever opened my mouth.

I've used the bit mask before with separate radio button fields.

When I heard about the Check Box feature I just threw a fast form together
and put a Check Box on it.
Burned again.

Anyway I can get it to do what I want with the bit mask and I can present
the 0-n of n choices for my (L)users in a check box GUI format.

It just seems right.
Circles - only one choice of many
Squares - one to many of many


But if you think about it Radio buttons went from round to
square(rectangles) in the early Sixties. My '62 Chevy II had square buttons
on its radio. And some radios - Sparkomatics I think - could give you extra
presets by hitting two buttons at once. Then there are FM1 FM2 type tuners
. . . . Shut UP Wesley!!!!!


John J. Reiser
Software Development Analyst
Remedy Administrator
voice: (856) 722-4743
fax: (856) 273-5149
Lockheed Martin
199 Borton Landing Rd.
MS 137-104
Moorestown, NJ 08057
Naval Electronics & Surveillance Systems - Surface Systems
The star that burns twice as bright burns half as long.
Pay close attention and be illuminated by its brilliance. - paraphrased by
me


-----Original Message-----
From: Black, Matt [mailto:matt.black@VERIZON.COM]
Sent: Friday, October 04, 2002 3:17 PM
To: ARSLIST@LISTSERV.QMXS.COM
Subject: Re: Overtime: Friday


**

Actually, I think the way to implement a "check box" (Selecting {0..N} of N
items) is with a "bitmask field".


One way to implement a "bitmask field" is to store an integer (whole number)
that is the sum of (2^N)'s.
If there are 5 options in the list then N could be 0 or 1 or 2 or 3 or 4.

If the first and last options are selected then you store. (2^1+2^4. = 1+16
=17)
If the second and third options are selected then you store. (2^1+2^2. =
2+4= 6)

(The sum of these values will always be unique. AKA, two combinations of
selected items will never sum to be the same number as a different
combination. 1,2,4,8,16)

(This concept is not beyond the Remedy programmers. They have been using
this idea for years. For a reference implementation, just look at how the
"Execute on" conditions is stored for an Active Link at the API level. Or
even at the values you can pass the APPLICATION-PERFORM-ACTIVE-LINK function
in v5.1 docs.)


My point is...

This behavior is not what a "Selection field" does. A selection
field only stores 0 or 1 or 2 or 3 or 4. So ARS is either "wrong" to
associate a "checkbox GUI" with an ARS selection field. Or the ARS "checkbox
GUI" is broken because it only offers only one value. You decide which is
"more wrong".

I think you end up with "wrong according to the standards" anyway
you look at it. My guess is that they will "fix this" in the future, and
wanted to give everyone a "box that has a checkmark appear when you select
it" sooner than then.


My "middle ground" would have been to make the two "GUI"'s ("box
with a checkmark" vs "circle with a dot in it") a straight replacement for
each other and not fight the fact that the field type only lets you pick one
value. Then later implement a new field type that lets you pick multiple
values at the same time, and also allow it to present with the same two
GUI's. (Or better yet, let me supply the field with two "pictures", one for
when an option is selected and one for when the option is not selected. I
could leave one blank and make the other a "Smiley", or a picture of a "Dog"
or anything else I choose to show that the option is "selected". Like maybe
an arrow "-->" in one case and "<--" on a different field. Oh the
possibilities...)


Let me say I'm sorry for taking this thread this far from humor. But
I hope it has been an interesting discussion all the same. :)

--
Carey Matthew Black

Solution = People + Process + Tools
Fast, Accurate, Cheap.... Pick two.

-----Original Message-----
From: Shannon Davis [mailto:sdavis@BCGI.NET]
Sent: Friday, October 04, 2002 11:46 AM
To: ARSLIST@LISTSERV.QMXS.COM
Subject: Re: Overtime: Friday


**

>I can only imagine it as a
>concatenation of values, which becomes
>detrimental to the performance of the
>application.

Here is how I would implement it. Checkboxes are a boolean field type that
are either *on* or *off*. They appear differently from a radio button (this
is important to the user, as you said). That's pretty much the only
difference, besides only allowing one check value.

The only thing that other gui-developers provide that Remedy doesn't is the
ability to group checkboxes. However, I think we have more freedom this
way. We can choose to have multiple checkboxes or only one. If we need to
store the user's choices, we can store in a hidden text field. We can use
filters to ensure that someone checks at least one.

Maybe even assign each of the checkboxes a bit that can be turned on and off
in your hidden text field. So you read your text field as 0110 or 1111
depending on how many boxes were checked or not checked.


---
Shannon B. Davis
Software Engineer - End User Applications
Boston Communications Group, Inc.
bcgi (781) 904-5328
sdavis@bcgi.net



You may control your subscription options, including UNSUBSCRIBE,and ACCESS
THE ARCHIVES at http://www.ARSLIST.org


You may control your subscription options, including UNSUBSCRIBE,and ACCESS THE ARCHIVES at http://www.ARSLIST.org

**

> -----Original Message-----
> From: Action Request System discussion list(ARSList)
> [mailto:ARSLIST@LISTSERV.QMXS.COM] On Behalf Of Mark Blankenship
> Sent: Friday, October 04, 2002 9:20 AM
> To: ARSLIST@LISTSERV.QMXS.COM
> Subject: Re: [ARSLIST] Overtime: Friday
>
>
> **
>
> Exactly!
>
> Check boxes vs. Radio buttons are a User Interface issue.
> Easier to learn and understand. Radio buttons mean 1 choice
> only, check boxes bean multiple choices.

Maybe zero or more choices. Maybe one or more choices. This
requirement should be configurable...

> And to the point of having one field that allowed multiple
> selections: How would you represent that in the data base?
> How, as a developer, would I use that data?
>
> I can only imagine it as a concatenation of values, which
> becomes detrimental to the performance of the application.

One method is a bit field. Take a word, for example. That's 16 bits.
So you can have 16 boolean choices stored in one integer field.

Storing something like this in the database is not the hardest part,
IMHO. It’s making sense of the data at the GUI level. If done wrong,
you have another selection field issue where the application developer
is acutely aware of the backend storage system and has to keep it in
mind as development continues. What you really want is to hide meta
data storage from the application developer.

> I think Remedy got it right on here. The only think I might have done
> differently:
> Made check box fields a completely different field type, as
> to avoid confusing the administrator. But, I could probably
> shoot some holes in that idea also.

One way would be a container field that allowed you to group these
fields in like manner to a tab field. Another possibility is different
field types as you mention.

> my 2 cents...keep the change :)
>
> Mark Blankenship
> Vista IT - Technology Office
> Austin, TX
> mailto:mark.blankenship@vistait.com


Dana Bourgeois

> -----Original Message-----
> From: Action Request System discussion list(ARSList)
> [mailto:ARSLIST@LISTSERV.QMXS.COM]On Behalf Of Parrish, Scott
> Sent: Friday, October 04, 2002 12:02 PM
> To: ARSLIST@LISTSERV.QMXS.COM
> Subject: Re: Overtime: Friday
>
>
> **
>
> My read into this functionality is that Remedy is forcing you
> to use the "checkbox GUI thing" the way it is intended.
> Frankly, using a checkbox to force a user to a single
> selection among a group of selections is poor design. (I
> understand that you already know this.) While the Radio vs.
> Checkbox thing may be a GUI thing, it does go beyond that. It
> is a usability issue. Users in the GUI world know that if
> they have a radio button with three selections, they may
> choose only one. The same user also knows that if there are
> three checkboxes they may choose to select none, one, two or
> all three. I really do not see any other way Remedy could
> have implemented the checkboxes, except to allow developers
> to use them in a manner in which they weren't intended. The
> same way we USED to be forced to use radio buttons to mimic
> checkbox functionality.
>
> That being said, I would have liked to have been able to put
> five selections in the attributes for the checkbox field and
> allowed the user to select any permutation of all five. Only
> thing is, I don't know how the ARS system could have
> implemented that type of functionality. But, maybe I'm just
> not thinking out of the box enough.
>
> Ok, off of my soapbox.
>
> Scott
>
> -----Original Message-----
> From: Black, Matt [mailto:matt.black@verizon.com]
> Sent: Friday, October 04, 2002 11:38 AM
> To: ARSLIST@LISTSERV.QMXS.COM
> Subject: Re: Overtime: Friday
>
>
> **
>
> Scott,
> Your right about this "being as designed".
>
>
> And I will add that I think Remedy missed the boat on this.
> What about the condition where you want the user to
> select 1 of the N options. If you want to use a checkbox
> "GUI" to do it then you have to create N selection fields,
> all set to use "checkbox" GUI, and then create workflow that
> makes sure the other 4 fields are "$ NULL$" when any of the
> five are selected. If one selection field could display all
> values with a checkbox for each, then this "extra stuff"
> would not be needed.
> True, if you want the user to pick more than one
> option, then there still would need to be multiple selection
> fields, but that is the same for the "Radio Button" GUI too.
>
> I understand that one selection field = one selection
> value at a time. That is fine. However the "Checkbox" Vs.
> "Radio Button" is a GUI thing and not a "Data" thing. By
> restricting the GUI Checkbox to only show the "first value"
> Remedy took something that might have been pretty to some
> and made it more of a pain. (If I want separate objects for
> each "checkbox", I could do that with buttons. (See the v4.5
> sample app.)
>
> --
> Carey Matthew Black
>
> Solution = People + Process + Tools
> Fast, Accurate, Cheap.... Pick two.
>
> -----Original Message-----
> From: Parrish, Scott [mailto:Scott.Parish@BELLSOUTH.COM]
> Sent: Friday, October 04, 2002 9:14 AM
> To: ARSLIST@LISTSERV.QMXS.COM
> Subject: Re: Overtime: Friday
>
>
> **
>
> John,
> No. The single checkbox is not a bug. In GUI design,
> checkboxes are either "On" or "Off". In a group of
> selections, check boxes allow for multiple choices among a
> group of choices while radio buttons are supposed to allow a
> single choice among a group. Because ARS will not allow you
> to make multiple selections in a radio/drop down/checkbox
> list, you must create individual fields for each checkbox. It
> is documented in the basic guide that even if you place
> multiple choices in the selection field, if it is a checkbox,
> only the first will show up.
>
> Hope this helps.
>
> Scott
> -----Original Message-----
> From: Reiser, John J [mailto:john.j.reiser@lmco.com]
> Sent: Friday, October 04, 2002 9:33 AM
> To: ARSLIST@LISTSERV.QMXS.COM
> Subject: Re: Overtime: Friday
>
>
> **
>
> Dan, The Executive Forum in Philadelphia announced RUG 2003
> will be in April/May in San Francisco.
>
> checkboxES? I've only been able to get one box to show up per
> field. Is this a bug? I might as well use single radio buttons.
>
> John J. Reiser
> Software Development Analyst
> Remedy Administrator
> voice: (856) 722-4743
> fax: (856) 273-5149
> Lockheed Martin
> 199 Borton Landing Rd.
> MS 137-104
> Moorestown, NJ 08057
> Naval Electronics & Surveillance Systems - Surface Systems
> The star that burns twice as bright burns half as long.
> Pay close attention and be illuminated by its brilliance. -
> paraphrased by me
>
>
> -----Original Message-----
> From: Dan Bloom, ARSList Founder and Administrator
> [mailto:dan.bloom@SYMPATICO.CA]
> Sent: Friday, October 04, 2002 9:11 AM
> To: ARSLIST@LISTSERV.QMXS.COM
> Subject: Overtime: Friday
>
>
> **
>
> If we have a RUG2003 and BMC has it's User Groups take part
> in it we will then have a BUG in a RUG.
>
>
>
> I am actually suprised that we haven't heard yet about when
> and where for RUG 2003, but I'm sure the folks are busy.
>
> And now I shall return to playing with Remedy 5.1 and trying
> to get check boxes to show up.
>
> .....dan
> Dan Bloom
> ARSList Founder and Administrator
>
>
>
>
> You may control your subscription options, including
> UNSUBSCRIBE,and ACCESS THE ARCHIVES at http://www.ARSLIST.org
>
>
>
>
> You may control your subscription options, including
> UNSUBSCRIBE,and ACCESS THE ARCHIVES at http://www.ARSLIST.org
>
>
> *****
> "The information transmitted is intended only for the person
> or entity to which it is addressed and may contain
> confidential, proprietary, and/or privileged material. Any
> review, retransmission, dissemination or other use of, or
> taking of any action in reliance upon, this information by
> persons or entities other than the intended recipient is
> prohibited. If you received this in error, please contact the
> sender and delete the material from all computers."
>
>
>
>
> You may control your subscription options, including
> UNSUBSCRIBE,and ACCESS THE ARCHIVES at http://www.ARSLIST.org
>
>
>
>
> You may control your subscription options, including
> UNSUBSCRIBE,and ACCESS THE ARCHIVES at http://www.ARSLIST.org
>
>
> *****
> "The information transmitted is intended only for the person
> or entity to which it is addressed and may contain
> confidential, proprietary, and/or privileged material. Any
> review, retransmission, dissemination or other use of, or
> taking of any action in reliance upon, this information by
> persons or entities other than the intended recipient is
> prohibited. If you received this in error, please contact the
> sender and delete the material from all computers."
>
>
>
>
> You may control your subscription options, including
> UNSUBSCRIBE,and ACCESS THE ARCHIVES at http://www.ARSLIST.org
>
>
>
> You may control your subscription options, including
> UNSUBSCRIBE,and ACCESS THE ARCHIVES at http://www.ARSLIST.org
>


You may control your subscription options, including UNSUBSCRIBE,and ACCESS THE ARCHIVES at http://www.ARSLIST.org

**

John,
I can not say that I remember '62. (That is a bit before "my time".
:)
Nice to know that somewhere in the early '62 the world got a bit
"more square". :)



--
Carey Matthew Black

Solution = People + Process + Tools
Fast, Accurate, Cheap.... Pick two.

-----Original Message-----
From: Reiser, John J [mailto:john.j.reiser@LMCO.COM]
Sent: Friday, October 04, 2002 2:52 PM
To: ARSLIST@LISTSERV.QMXS.COM
Subject: Re: Overtime: Friday




But if you think about it Radio buttons went from round to
square(rectangles) in the early Sixties. My '62 Chevy II had square buttons
on its radio. And some radios - Sparkomatics I think - could give you extra
presets by hitting two buttons at once. Then there are FM1 FM2 type tuners
. . . . Shut UP Wesley!!!!!


John J. Reiser


You may control your subscription options, including UNSUBSCRIBE,and ACCESS THE ARCHIVES at http://www.ARSLIST.org

**

Ummm....no. You can't place the theory of GUI design at the doorstep of
either Microsoft or Apple. Its independent of them. You can blame them
for common practice perhaps based on choices they make in their
products, their market share and what people end up getting used to.
But the theory of good GUI design is based on research, not practice.
Microsoft has, in their products, done some things right and done some
things wrong.

Dana Bourgeois

I would *love* to get my hands around the neck of Microsoft person who
decided that pop up windows should lock. This is horrible behavior and
has its roots in single-tasking DOS-based Windows GUI rules. Alerts
should lock (and always end on top). Pop up sub-windows should not.
But they do uniformly in Microsoft products which is good in its
consistency but really bad overall. 3M has probably sold millions of $$
worth of sticky notes because of this one design decision.

> -----Original Message-----
> From: Action Request System discussion list(ARSList)
> [mailto:ARSLIST@LISTSERV.QMXS.COM] On Behalf Of Parrish, Scott
> Sent: Friday, October 04, 2002 11:38 AM
> To: ARSLIST@LISTSERV.QMXS.COM
> Subject: Re: [ARSLIST] Overtime: Friday
>
>
> **
>
> Short answer to your lengthy email. And yes, I did read it all.
>
> I have been a Remedy developer for a relatively short period
> of time. One of the things I wanted to do really quick when I
> got into this was to learn the proper design practices for
> GUI interfaces. I new that just because I could click on a
> field and paste it on the page that I was no where near an
> expert at designing forms. Thus, my hunt began online at
> Amazon.com and Barnes & Noble for design books. I found a
> few. The GUI Bloopers book that is now referenced in the 5.1
> documentation and also referenced at RUG 2000 during one of
> the sessions, is one of the better ones. WebPagesThatSuck is
> another good one. Although it is intended for web design,
> some of the same rules apply.
>
> In a previous life, long ago, I was a sports writer and
> assistant sports editor, responsible for the layout and
> design of newspaper pages. I knew from that experience that
> somebody, somewhere has a set of standards for what should
> and should not be done, whether it be GUI design, newspaper
> design or building cars. Microsoft Press (i can hear EVERYONE
> yawning right now) has a book on standard design principles.
> I am sure there are more.
>
> So, to answer your question, WHO is responsible for this
> "Radio button is 1 of N while Checkboxes are X of N?" I would
> daresay, Microsoft; maybe even Apple going back to the first
> MacIntosh. I don't know, but I do know it is a standard.
>
> Ok, break time is over, everyone back on your heads.
>
> Scott
>
> -----Original Message-----
> From: Black, Matt [mailto:matt.black@verizon.com]
> Sent: Friday, October 04, 2002 1:33 PM
> To: ARSLIST@LISTSERV.QMXS.COM
> Subject: Re: Overtime: Friday
>
>
> **
>
> Scott,
>
> First, thanks for the response (Same to you to
> Brian.) I do appreciate hearing other peoples perspectives.
> (They often tell me what I do not know, and help to show me
> new ways to look at the world around me.)
>
>
> This user never put that together. (AKA: Radio Button
> = one of n, Checkboxes = (0[1?]..n) of n) I did however,
> check www.w3c.org and confirm that your basic explanation is
> substantially correct for HTML v4.01. (There were a few
> interesting notes about what is "undefined behavior" too.
> http://www.w3.org/TR/html4/interact/forms.html#checkbox ) I
> selected HTML, because it is the "killer app" environment
> that most "modern" applications strive to be a part of.
> (Cough.. Cough..)
>
> I really viewed the "Radio Button" vs. "Checkboxes"
> as a "purely stylistic" difference. The logic that suggest
> that these GUI's means something different is interesting. (I
> guess here is where I show that I have written more Perl
> code, without GUI's, then "GUI" applications outside of ARS. :)
>
> So with that said.
>
>
>
> ARS selection fields only allow for a single
> selection, and they allow for no selection at all.
> So it is not correct to implement a "checkbox" GUI
> on top of that object. (It does not match the "intended"
> design of checkboxes.) In fact, it does not match the
> "design" of HTML radio buttons either. (They require that a
> value be selected. See the URL's above.)
>
> AKA: Remedy still missed the "conventional" boat.
>
>
>
>
> (In my simple view of applications.)
> I think it is questionable as to if this GUI
> convention, is necessary.
> For example (and it is a bit ridiculous) If a user
> was given the following list. What would you expect them to
> do? (besides laugh at the stupidity of the details in this example.)
>
> What is your age:
> 1) 0-12
> 2) 0-17
> 3) 0-25
> 4) 18-65
> 5) 65+
>
> [I have intentionally not defined what type of GUI is used to
> describe this list.]
>
> The first thing the user will likely think".. "Why is
> there '0-12' and '0-17'?" However if the user is between
> 12-17 this list can determine that. Provided that the user
> selects the first two options. (I know why not just do 0-12
> and 13-17, but the point is that the groupings on the list
> are defined by the what the application "needs". There may be
> a case where the application needs to "test" to see if the
> user is "entering consistent data" and "duplication of
> options makes sense". There are also other "application
> needs" that might allow for "overlap" in the listed options.)
>
> The next thought the user might have face is.. "Ok,
> I'm in more than one, what do I do?" If the list was in a
> GUI, I'm sure they would attempt to "click" on each option
> that applies. (or at least the one that applies "best". They
> could also be lazy and not try the other options.)
> In the event that the GUI displays that only one
> option can be selected then the would leave the one that
> applies the "best" as selected and try to move on.
> In the event that the GUI displays that multiple
> options can be selected then I would expect that they would
> to select all that apply.
>
> (Maybe it's just my users, but they seem to click on
> everything 6 times before the decide that it was the right
> thing to click on. You ever watch a user using an
> application? They get board "thinking about what they are
> doing" and turn into a "click-o-matic".)
>
> Would it so confuse the users if the "checkboxes" had
> little "x"'s in the box instead of an actually "check mark"?
> (Or would that be a third type of GUI that could have a third
> "expected behavior" by the users?) Maybe Remedy should use a
> square box with a round "check mark" to describe a (0 or
> 1) of n "selection field"?
> (I doubt that any of that would confuse a reasonably
> intelligent user. I know, there is that oxymoron again...
> "intelligent user"... )
>
>
>
> Now let me try to switch your train of thought to a new track...
>
> If the following list was presented from a command line
> script. What would the user think then? How do you expect
> them to react if the "interface" is a command line? (maybe
> answer with 0,1 or 01 (until they answer with no
> answer) and what happens when the press ? Do they get a
> list back like:
>
> 1)*0-12
> 2) 0-17
> 3) 0-25
> 4) 18-65
> 5) 65+
>
> Then:
>
> 1)*0-12
> 2)*0-17
> 3) 0-25
> 4) 18-65
> 5) 65+
>
> Or do they just get the "next prompt"? (or error because they
> failed to select any?)
>
>
> My point is simple... "Don't fence me in". Even at
> the cost of allowing me to "break conventions".
>
> Just because I can, does not mean that I should, or
> will do something. It's about "Freedom baby"! Freedom to make
> all the stupid mistakes that you want to. Which is also the
> power to create "the next best thing since sliced bread". We
> learn through mistakes. We create best, without boundaries.
>
>
> Maybe, just maybe, ARS will "redefine application
> conventions" because it will "take over the world!!!!"
>
>
>
>
> I guess I am so "unaware of the GUI box" that I don't want to
> be limited by it.
>
> BTW: "the way it is intended"... By whom? (Who invented the
> "Checkbox GUI" and defined how it should work? If you have a
> verifiable name, I may just fall out of my chair. :)
>
> --
> Carey Matthew Black
>
> Solution = People + Process + Tools
> Fast, Accurate, Cheap.... Pick two.
>
> -----Original Message-----
> From: Parrish, Scott [mailto:Scott.Parish@BELLSOUTH.COM]
> Sent: Friday, October 04, 2002 11:02 AM
> To: ARSLIST@LISTSERV.QMXS.COM
> Subject: Re: Overtime: Friday
>
>
> **
>
> My read into this functionality is that Remedy is forcing you
> to use the "checkbox GUI thing" the way it is intended.
> Frankly, using a checkbox to force a user to a single
> selection among a group of selections is poor design. (I
> understand that you already know this.) While the Radio vs.
> Checkbox thing may be a GUI thing, it does go beyond that. It
> is a usability issue. Users in the GUI world know that if
> they have a radio button with three selections, they may
> choose only one. The same user also knows that if there are
> three checkboxes they may choose to select none, one, two or
> all three. I really do not see any other way Remedy could
> have implemented the checkboxes, except to allow developers
> to use them in a manner in which they weren't intended. The
> same way we USED to be forced to use radio buttons to mimic
> checkbox functionality.
>
> That being said, I would have liked to have been able to put
> five selections in the attributes for the checkbox field and
> allowed the user to select any permutation of all five. Only
> thing is, I don't know how the ARS system could have
> implemented that type of functionality. But, maybe I'm just
> not thinking out of the box enough.
>
> Ok, off of my soapbox.
>
> Scott
>
>
>
> You may control your subscription options, including
> UNSUBSCRIBE,and ACCESS THE ARCHIVES at http://www.ARSLIST.org
>
>
> *****
> "The information transmitted is intended only for the person
> or entity to which it is addressed and may contain
> confidential, proprietary, and/or privileged material. Any
> review, retransmission, dissemination or other use of, or
> taking of any action in reliance upon, this information by
> persons or entities other than the intended recipient is
> prohibited. If you received this in error, please contact the
> sender and delete the material from all computers."
>
>
>
> You may control your subscription options, including
> UNSUBSCRIBE,and ACCESS THE ARCHIVES at http://www.ARSLIST.org
>


You may control your subscription options, including UNSUBSCRIBE,and ACCESS THE ARCHIVES at http://www.ARSLIST.org

**

What you are talking about is the difference between a modal dialog
(locked) and a modeless dialog (unlocked).

Actually both have *VERY* legitimate reasons for existing. The modal
dialog should be used when input is required before the application can
continue (for example: id and password).

Modeless dialogs on the other hand should be used whenever the
application execution can continue without the input (color palettes in
Photoshop, etc.)


Sean Cundiff
Application Programmer III
Southern Illinois University, Carbondale
Carbondale, IL 62901-6633
Phone: 618.453.4029 Fax: 618.453.4152

"Vigilance With Pride"


-----Original Message-----
From: Action Request System discussion list(ARSList)
[mailto:ARSLIST@LISTSERV.QMXS.COM] On Behalf Of Dana Bourgeois
Sent: Friday, October 04, 2002 4:41 PM
To: ARSLIST@LISTSERV.QMXS.COM
Subject: Re: Overtime: Friday



I would *love* to get my hands around the neck of Microsoft person who
decided that pop up windows should lock. This is horrible behavior and
has its roots in single-tasking DOS-based Windows GUI rules. Alerts
should lock (and always end on top). Pop up sub-windows should not.
But they do uniformly in Microsoft products which is good in its
consistency but really bad overall. 3M has probably sold millions of $$
worth of sticky notes because of this one design decision.


You may control your subscription options, including UNSUBSCRIBE,and ACCESS THE ARCHIVES at http://www.ARSLIST.org

**

Oh, jeez, Brian! Jobs stole from Xerox PARC, and Gates stole from
Jobs. Strike that. Gates stole from everybody. But back to the
problem at hand.

Checkboxes in HTML can be implemented as single, standalone fields with
an on/off attribute. Or they can be clustered together under the same
control name. (As Matt pointed out.)

I think Remedy's implementation is half-assed as long a you can't
cluster the output into a single entity that you can test and query on.
How that's done is open to discussion. In JavaScript you access the
values as elements in an array. In Perl's CGI.pm, they're hashes. I
like Zandi's bitmask idea, which reminds me of Unix's permission
numbers. It's simple, compact, and elegant.

There are often very good reasons for clustering checkboxes. Imagine a
medical form that lists several medications. You tell the users to
check any medications they're allergic to. Do you REALLY want to query
on 20 different fields? I don't. I'd rather be able to say:

$Allergic To$ = "Aspirin" OR $Allergic To$ =
"Penicillin", etc.

That might be an oversimplification. Maybe it would be better to
access the values using notation like Status History... Like this:

$AllergicTo.Aspirin" = 'Yes' OR $AllergicTo.Penicillin" =
'Yes'

Yeah. I like that.

The most obvious example in the Remedy environment I can think of (and
forgive me if somebody already brought this up) is the Group List field
on the User form. You can imagine the Group List field presented as a
list of checkboxes with the instruction: "Click all that
apply." In this case a user can belong to any combination of
groups. It isn't a perfect example, but you see what I'm getting at.

If Remedy is going to stick with this implementation of a checkbox as a
single, square, glorified radio button, that's fine, but I still think
we need a collector field like the Group List field or a container like
Status History that we can query/test on.

But that's just one man's opinion.

--Tim

--- Brian Goralczyk <Brian.Goralczyk@VERIZONWIRELESS.COM> wrote:
> **
>
> Matt,
>
> I have two names. Steve Jobs, and Bill Gates. The founding
fathers
> of
> modern graphical interfaces
>
*cough**cough**cough**cough**cough**cough**cough**hack**gag**choke*
>
> Sorry, couldn't resist. But really, I believe that environments
that
> have
> been around for longer, or at least offered the functionality
longer,
> have
> the right to decide how it should be used, and by far, the
language
> that
> saturates the market is usually the one that set the industry
> standard. I
> know my graphical environment knowledge is somewhat limited.
HTML,
> VB,
> Remedy. But I feel that out of these, check boxes have been used
> somewhat
> consistently. Some one feel free to correct me.
>
> I know that, myself as a user, would probably send off a scathing
> email to a
> programmer that gave me a list like :
>
> What is your age:
> 1) 0-12
> 2) 0-17
> 3) 0-25
> 4) 18-65
> 5) 65+
>
> I also realize that your list was speculation. But it would be
> extremely
> bad gui design to do something like that. A book that I have
found
> useful
> and recommended to other developers is Gui Bloopers. It somewhat
> coincides
> with www.websitesthatsuck.com but offers a lot of useful insight.
On
> that
> note, I suggest all developers of Graphical User Interfaces go
read
> the
> book. I am certain that some knowledge will be gained.
>
> HTH,
>
> Brian
>
> -----Original Message-----
> From: Black, Matt [mailto:matt.black@verizon.com]
> Sent: Friday, October 04, 2002 1:33 PM
> To: ARSLIST@LISTSERV.QMXS.COM
> Subject: Re: [ARSLIST] Overtime: Friday <Humour>
>
>
> **
>
> Scott,
>
> First, thanks for the response (Same to you to Brian.) I
do
> appreciate hearing other peoples perspectives. (They often tell me
> what I do
> not know, and help to show me new ways to look at the world around
> me.)
>
>
> This user never put that together. (AKA: Radio Button =
one
> of n,
> Checkboxes = (0[1?]..n) of n) I did however, check www.w3c.org and
> confirm
> that your basic explanation is substantially correct for HTML
v4.01.
> (There
> were a few interesting notes about what is "undefined
behavior" too.
> http://www.w3.org/TR/html4/interact/forms.html#checkbox ) I
selected
> HTML,
> because it is the "killer app" environment that most
"modern"
> applications
> strive to be a part of. (Cough.. Cough..)
>
> I really viewed the "Radio Button" vs.
"Checkboxes" as a
> "purely
> stylistic" difference. The logic that suggest that these GUI's
means
> something different is interesting. (I guess here is where I show
> that I
> have written more Perl code, without GUI's, then "GUI"
applications
> outside
> of ARS. :)
>
> So with that said.
>
> <soapbox>
> <usingcommonGUIconventions>
> ARS selection fields only allow for a single selection,
and
> they
> allow for no selection at all.
> So it is not correct to implement a "checkbox"
GUI on top
> of that
> object. (It does not match the "intended" design of
checkboxes.) In
> fact, it
> does not match the "design" of HTML radio buttons either.
(They
> require that
> a value be selected. See the URL's above.)
>
> AKA: Remedy still missed the "conventional" boat.
>
> <usingcommonGUIconventions>
>
> <NotfollowingcommonGUIconventions>
> (In my simple view of applications.)
> I think it is questionable as to if this GUI convention,
is
> necessary.
> For example (and it is a bit ridiculous) If a user was
given
> the
> following list. What would you expect them to do? (besides laugh
at
> the
> stupidity of the details in this example.)
>
> What is your age:
> 1) 0-12
> 2) 0-17
> 3) 0-25
> 4) 18-65
> 5) 65+
>
> [I have intentionally not defined what type of GUI is used to
> describe this
> list.]
>
> The first thing the user will likely think".. "Why
is there
> '0-12'
> and '0-17'?" However if the user is between 12-17 this list
can
> determine
> that. Provided that the user selects the first two options. (I
know
> why not
> just do 0-12 and 13-17, but the point is that the groupings on the
> list are
> defined by the what the application "needs". There may be
a case
> where the
> application needs to "test" to see if the user is
"entering
> consistent data"
> and "duplication of options makes sense". There are also
other
> "application
> needs" that might allow for "overlap" in the listed
options.)
>
> The next thought the user might have face is.. "Ok,
I'm in
> more than
> one, what do I do?" If the list was in a GUI, I'm sure they
would
> attempt to
> "click" on each option that applies. (or at least the one
that
> applies
> "best". They could also be lazy and not try the other
options.)
> In the event that the GUI displays that only one option
can
> be
> selected then the would leave the one that applies the
"best" as
> selected
> and try to move on.
> In the event that the GUI displays that multiple options
can
> be
> selected then I would expect that they would to select all that
> apply.
>
> (Maybe it's just my users, but they seem to click on everything 6
> times
> before the decide that it was the right thing to click on. You
ever
> watch a
> user using an application? They get board "thinking about what
they
> are
> doing" and turn into a "click-o-matic".)
>
> Would it so confuse the users if the "checkboxes"
had little
> "x"'s
> in the box instead of an actually "check mark"? (Or would
that be a
> third
> type of GUI that could have a third "expected behavior" by
the
> users?) Maybe
> Remedy should use a square box with a round "check mark"
to describe
> a (0 or
> 1) of n "selection field"?
> (I doubt that any of that would confuse a reasonably intelligent
> user. I
> know, there is that oxymoron again... "intelligent
user"... )
>
>
>
> Now let me try to switch your train of thought to a new track...
>
> If the following list was presented from a command line script.
> What
> would the user think then? How do you expect them to react if the
> "interface" is a command line? (maybe answer with 0,1 or
0<cr>1<cr>
> (until
> they answer with no answer) and what happens when the press
<cr>? Do
> they
> get a list back like:
>
> 1)*0-12
> 2) 0-17
> 3) 0-25
> 4) 18-65
> 5) 65+
>
> Then:
>
> 1)*0-12
> 2)*0-17
> 3) 0-25
> 4) 18-65
> 5) 65+
>
> Or do they just get the "next prompt"? (or error because
they failed
> to
> select any?)
>
>
> My point is simple... "Don't fence me in". Even at
the cost
> of
> allowing me to "break conventions".
>
> Just because I can, does not mean that I should, or will
do
> something. It's about "Freedom baby"! Freedom to make all
the stupid
> mistakes that you want to. Which is also the power to create
"the
> next best
> thing since sliced bread". We learn through mistakes. We
create best,
> without boundaries.
>
> <spookymusic lights ="dimming">
> Maybe, just maybe, ARS will "redefine application
> conventions"
> because it will "take over the world!!!!"
> </spookymusic>
> </NotfollowingcommonGUIconventions>
> </soapbox>
>
>
> I guess I am so "unaware of the GUI box" that I don't want
to be
> limited by
> it.
>
> BTW: "the way it is intended"... By whom? (Who invented
the "Checkbox
> GUI"
> and defined how it should work? If you have a verifiable name, I
may
> just
> fall out of my chair. :)
>
> --
> Carey Matthew Black
>
> Solution = People + Process + Tools
> Fast, Accurate, Cheap.... Pick two.
>
> -----Original Message-----
> From: Parrish, Scott [mailto:Scott.Parish@BELLSOUTH.COM]
> Sent: Friday, October 04, 2002 11:02 AM
> To: ARSLIST@LISTSERV.QMXS.COM
> Subject: Re: Overtime: Friday <Humour>
>
>
> **
>
> My read into this functionality is that Remedy is forcing you to
use
> the
> "checkbox GUI thing" the way it is intended. Frankly,
using a
> checkbox to
> force a user to a single selection among a group of selections is
> poor
> design. (I understand that you already know this.) While the Radio
> vs.
> Checkbox thing may be a GUI thing, it does go beyond that. It is a
> usability
> issue. Users in the GUI world know that if they have a radio
button
> with
> three selections, they may choose only one. The same user also
knows
> that if
> there are three checkboxes they may choose to select none, one,
two
> or all
> three. I really do not see any other way Remedy could have
> implemented the
> checkboxes, except to allow developers to use them in a manner in
> which they
> weren't intended. The same way we USED to be forced to use radio
> buttons to
> mimic checkbox functionality.
>
> That being said, I would have liked to have been able to put five
> selections
> in the attributes for the checkbox field and allowed the user to
> select any
> permutation of all five. Only thing is, I don't know how the ARS
> system
> could have implemented that type of functionality. But, maybe I'm
> just not
> thinking out of the box enough.
>
> Ok, off of my soapbox.
>
> Scott
>
>

>
> You may control your subscription options, including
UNSUBSCRIBE,and
> ACCESS
> THE ARCHIVES at http://www.ARSLIST.org
>
>

> You may control your subscription options, including
UNSUBSCRIBE,and
> ACCESS THE ARCHIVES at http://www.ARSLIST.org



Do you Yahoo!?
Faith Hill - Exclusive Performances, Videos & More
http://faith.yahoo.com


You may control your subscription options, including UNSUBSCRIBE,and ACCESS THE ARCHIVES at http://www.ARSLIST.org

**

Sean

That's one of the enhancement requests I've submitted - to have an extra
option on the Window Open action to open a form as a non-modal dialog box...

David Sanders
Remedy Consultant
=================
tel +44 (0)1494 468989
mobile +44 (0)7710 377761
email mailto:david.sanders@westoverconsulting.co.uk
web http://www.westoverconsulting.co.uk/

View Enterprise Service Suite - CRM Sales automation, Support and Training -
http://www.westoverconsulting.co.uk/ESS



-----Original Message-----
From: Action Request System discussion list(ARSList)
[mailto:ARSLIST@LISTSERV.QMXS.COM]On Behalf Of Sean Cundiff
Sent: 04 October 2002 23:10
To: ARSLIST@LISTSERV.QMXS.COM
Subject: Re: Overtime: Friday


**

What you are talking about is the difference between a modal dialog
(locked) and a modeless dialog (unlocked).

Actually both have *VERY* legitimate reasons for existing. The modal
dialog should be used when input is required before the application can
continue (for example: id and password).

Modeless dialogs on the other hand should be used whenever the
application execution can continue without the input (color palettes in
Photoshop, etc.)


Sean Cundiff
Application Programmer III
Southern Illinois University, Carbondale
Carbondale, IL 62901-6633
Phone: 618.453.4029 Fax: 618.453.4152

"Vigilance With Pride"


-----Original Message-----
From: Action Request System discussion list(ARSList)
[mailto:ARSLIST@LISTSERV.QMXS.COM] On Behalf Of Dana Bourgeois
Sent: Friday, October 04, 2002 4:41 PM
To: ARSLIST@LISTSERV.QMXS.COM
Subject: Re: Overtime: Friday



I would *love* to get my hands around the neck of Microsoft person who
decided that pop up windows should lock. This is horrible behavior and
has its roots in single-tasking DOS-based Windows GUI rules. Alerts
should lock (and always end on top). Pop up sub-windows should not.
But they do uniformly in Microsoft products which is good in its
consistency but really bad overall. 3M has probably sold millions of $$
worth of sticky notes because of this one design decision.



You may control your subscription options, including UNSUBSCRIBE,and ACCESS
THE ARCHIVES at http://www.ARSLIST.org



You may control your subscription options, including UNSUBSCRIBE,and ACCESS THE ARCHIVES at http://www.ARSLIST.org