Oh yes, I'm doing that all over the place for cross-references (from
one card to another in a Reference substack). The buttons in question
are navigation on a different level -- connections to further
information on some detail of the topic a card addresses.
Sorry to jump in so late in this
Oh, I think as a generalization that makes excellent sense. In this
particular case, it may or may not. This is a straight, lame, read-
this-card tutorial app; some cards are too long not to scroll
(already less than ideal from a UI standpoint, but I don't want to
make the stack as big as the bigg
Charles,
That's so true and maybe we will see some great changes in HIG in the
future. But I wonder if the interface should match the point unless of
course as an example. Of course you can do it, but is it then more like
an artists statement or a designers point? Will the users of the
Tutori
Sure -- though this is exactly not (if not _exactly_ the opposite of)
the tutorial situation I'm talking about. That is: if the
*abstruseness* of some information is part of the point of that
information, doesn't an interface for getting at it that makes the
path to it *not* automatic reinf
Not if Lind, Johnson & Sandblad are correct.
In fact, I rmember being in a situation many moons ago in which I was
failing a third semester calculus class (working my way up from an "F" to
a hoped-for "C").
As I had eventually noticed that my instructor tended to just take exam
problems that were
I'll love to see it finished too . . . It may be a while; it's got
*lots* of finicky little pieces.
On Jul 5, 2005, at 8:43 AM, Thomas McGrath III wrote:
I would love to see your stack when finished.
GL
Charles Hartman
Professor of English, Poet in Residence
Connecticut College
[EMAIL PR
Yes, and one of my favorites to use in teaching is "The Art of the
Obvious" (Lind, Johnson & Sandblad, CHI 1992).
While it is largely concerned with "automatically processed components of
the task of reading frequently used documents", the authors contend that
their findings suggest "implications
On July 5, 2005 6:31:06 AM CDT Tom III wrote:
2 cents:
I agree. It is not good moving buttons in fields or groups. It makes it
too hard for users to develop a motor plan for those buttons. A motor
plan is what happens during touch typing or even during walking where
our muscles develop a plan to
Charles,
I am a firm believer in "Rules are meant to be broken" and KISS (Keep
it simple stupid). I am also a Rebel at heart so I take the suggestions
from people about good form and then 'see' what it might look like in
real life. If my alternative solution works and is good enough than I
go
Yes, but couldn't it be argued that in this sense a tutorial app --
in effect, just a slicker & thinner alternative to a textbook -- has
requirements-on-the-user's-attention different from a normal,
"productive" app? Even *opposite* requirements? Slow 'em down! Block
that skimming! OK, I kn
2 cents:
I agree. It is not good moving buttons in fields or groups. It makes it
too hard for users to develop a motor plan for those buttons. A motor
plan is what happens during touch typing or even during walking where
our muscles develop a plan to those activities without having to think
a
I'd be inclined to have the More Info button outside the field and
have it activate only when appropriate (e.g., when the user has
scrolled all the way through the field or reached a certain point or
whatever).
But that's just me.
Dan
On Jul 4, 2005, at 2:30 PM, Charles Hartman wrote:
Oh
Cool!
On Jul 4, 2005, at 5:25 PM, Richard Gaskin wrote:
WOW - I would love scrolling text fields with pictures!
-- and buttons! (At the moment I'm doing this is a non-scrolling
field inside a scrolling group, but aside from being tedious that
has other disadvantages, such as the scrol
Oh, I think as a generalization that makes excellent sense. In this
particular case, it may or may not. This is a straight, lame, read-
this-card tutorial app; some cards are too long not to scroll
(already less than ideal from a UI standpoint, but I don't want to
make the stack as big as th
WOW - I would love scrolling text fields with pictures!
-- and buttons! (At the moment I'm doing this is a non-scrolling
field inside a scrolling group, but aside from being tedious that has
other disadvantages, such as the scroll-wheel not working right.)
To get scroll wheel support you c
Just my two cents -- and it's a holiday here so my brain may be
otherwise engaged -- I think putting buttons into scrolling fields is
a terrible UI idea. By definition, it puts certain functionality out
of the reach of the user until and unless s/he scrolls the field.
Lotus NOtes allowed th
Richmond,
As you are probably less of a goober than I, take a look at imageSource.
While in my current harried state I was not able to get it to work, I know
that others have. This allows you to do precisely what you desire (well,
okay, I don't know about the precision part...).
Judy
On Fri, 1
On Jul 1, 2005, at 1:04 PM, Mathewson wrote:
I have just downloaded the SuperCard 4.5 demo and found
they have a new feature:
allowObjects
this lets the user embed object (images and so on) inside
FIELDS:
WOW - I would love scrolling text fields with pictures!
-- and buttons! (At the mome
Hi son of Matthew :-),
WOW - I would love scrolling text fields with pictures!
ImageSource was introduced in Rev 1.1
Specifies an image to be displayed in place of the specified
character in a field.
set the imageSource of character to {imageID |imageName |imageURL |
empty}
So...
Best Re
19 matches
Mail list logo
