Post by Frederico MuñozThis is why I stoped using the tabs. But popup
switching is less intrusive and makes the
initial view stand out in relation to the
others. At least it looks that way to me when
looking at it.
A popup, for the purposes of this discussion,
doesn't have any advantage over a tab view. It
also hides the other pages away, and thus
displays only a fraction of available info. To
say it in an exaggerated way: Half your users
will simply overlook the popup (while a tab
control is at least obvious enough it can't be
missed), while the other half will have to try
each menu item and look at each page to find out
they really don't need it. Okay, maybe if you put
a label on the popup you could improve that a
little, but I don't think either of these
navigation schemes are a good fit in this case.
Post by Frederico MuñozIn the case of the Readme I still think that it
could be an option, mainly because the different
"documents" being presented are indeed of equal
importance, so a tab view would probably work.
But I can also see it working without them, so I
don't have a rigid opinion on this part,
whatever works better.
The problem with these documents is that
actually, most of the information in them is
probably useless to people using the installer. A
regular "Readme" contains contact information,
web site URLs, and lots of other info you don't
care about in an installer. If you want people to
create good installers, you may probably want to
encourage them to write sensible text specific to
the installer. Otherwise, half of the Readmes
will be overly verbose and misleading.
Post by Frederico MuñozPost by Frederico MuñozThe cannot "open" a package, for that they can use GWorkspace. The extra
information they have is described above.
Well, if they can open a package in GWorkspace, there should probably also
be an "open" menu item in Installer.app, just in case someone opens
Installer.app itself in GWorkspace.
Yes, that's possible, I'll just say to NSWorkspace to open the app bundle.
Not sure I understand this. My point is simply
that pretty much all apps let you double-click
them and then choose "Open" to pick a document
and open it. Installer shouldn't be an exception
here. An installer package is just another kind
of document. Just base your app on NSDocument and
let AppKit take care of all of this for you.
Post by Frederico MuñozI think that it makes the initial presentation
simple and easy to understand while
making available other ways of viewing the
installation process, but without imposing
them. This allows the user to "grow", as it
were, in his usage of the application, *if*
he wishes to do so.
There are better ways to do this. E.g. MacOS
supports "disclosure triangles" that are at the
bottom of the window, and enlarge the window when
"opened" to show more options. This works very
well, and expands on an existing concept people
also find in NSOutlineView. Using a tab view or a
switcher popup actually raises expectations in
your users that the app is more complex than it
seems.
Post by Frederico MuñozIt also follows a general way of presenting things relating to a
single thing, namely in the inspectors, etc.
I'm sorry, I don't understand this sentence. Can
you provide some more context? What "single
thing"? I'm lost.
Post by Frederico Muñoz-> The progress bar is only shown once the
installation has been started. As
such, it should probably be a modal window that is shown after the user has
clicked "Install". Adding a third page for "Progress" to the tab view would
be useless. The user can't interact with it, and it'll always display "0%
complete". There's no use in seeing it unless it's needed.
(...) But the progress is indeed at 0%, and if the
user choses a small-footprint option named
"Progress" before installing the application
that is what he should expect to see.
Why? What does the user care where this progress
indicator will be, if all it is is dead weight?
Try to see this as a user: Would you open an
application, and want to see a progress bar (as a
self-sufficient task)? One that you *know* will
be at 0%? Where in your feature list does it say
"The user needs to be able to look at an inactive
progress bar"?
It simply says the user should be able to
install stuff. If you follow Human Interface
Guidelines, you will notice that the user wants
to know when the computer is busy and won't
accept input, and how long it will take until the
computer is finished executing the user's
command. That is the purpose of a progress bar
and of your detailed log. To inform the user
*while* something is happening, *that* it is
happening, and *what* is happening.
While the installation is in progress, the user
shouldn't be able to work in the installer (or at
least not with that particular window). A modal
panel seems the natural choice.
Post by Frederico MuñozThe main thing here is that I find that the popup
switch is non-intrusive enough and that it makes
the default initial view the one that
gets the user attention (tabs, on the other
hand, since they display the topics at the
top, gives an idea of equal importance.
I'm not sold we even need the pages you have
right now. As you may have noticed, the pages my
mockup has are completely different. What you had
as pages, I have in separate windows that you can
call up from the "Window" menu.
Post by Frederico MuñozAnother thing to consider is the pervasiveness
of the popup switch in GNUstep to deal
with this kind of situations. The user, after
seing the way things work, should feel more
comfortable with it since it is present in other
apps. That's one of the strenghts NeXT
had IMHO, the design choices were consistent.
There's always something to be said for
consistency, and there's no need to reinvent the
wheel if there already is a control for this
function. However, programmers tend to use views
that have the same implementation (and thus are
superficially similar in functionality) but
different semantics as if they were exchangeable.
A (by now) obvious but still common example of
this mistake is the use of checkboxes for
mutually-exclusive choices, or the use of
radiobuttons for non-exclusive choices.
Similarly, a page-switcher popup or tab view
doesn't have the right semantics for my initial
idea of a sequential installation process.
However, you said you didn't want that
sequentiality, so let's not dwell on that. We
don't need several pages here, because pages
aren't supposed to be different views on the same
content, but rather pages are supposed to differ
in content.
To switch views, there are much better
approaches, like disclosure triangles (or buttons
that perform the same function), additional
windows, or a set of mutually exclusive
push-and-lock buttons.
Post by Frederico MuñozNo, you are understanding it correctly, the log
just says what it the program is doing
(Writing file XXX to YYY...). What you prupose
is certainly a way to do it (I think it is the
way GNOME does it IIRC).
I actually had a NSPanel poping up to show the
progress bar, but I removed it. I found
it awkward to use, but this can be related to my
general dislike for popup windows that
could be avoided. In this specific situation
But this specific pont is something that has
been bothering me. As I said, I initially went
for
the NSPanel version. Maybe I didn't like my
particular way of doing it, but what you propose
makes sense and is maybe the most logical way to put it.
You could also disable the window contents and
put a progress bar at the bottom, but I
personally don't like that because it is easy for
novice users to miss that the progress bar became
active (newbies tend to have a sort of
tunnel-view of the screen, and often miss things
happening at a distance from where they currently
are reading or where the mouse is, while with
more practice users tend to develop a better
peripheral view of the screen).
If this was MacOS X, I'd have two other options:
1) Do an animated resize of the window to make it
smaller and replace its contents with the
contents for the progress panel. I don't know
whether GNUstep can support animated resizes,
though... But this would both get rid of the
installer window contents (which the user
shouldn't use while it's being installed anyway)
and make it obvious it is in progress now. And
animated changes are harder to miss, because they
happen over a longer stretch of time. It would
also replace the modal panel, and thus allow the
user to run other installers simultaneously.
2) Use a progress sheet instead of the modal
panel. Sheets are window-modal, not
application-modal, and thus let you open and
launch another installer while this one is busy,
just like #1.
OTOH, it is hard to write the installer that can
run two installations simultaneously, so it would
probably be better to just go with the modal
panel and forget all of this again.
Post by Frederico MuñozActually this is exactly why I did it: the
buttons (with Install at the head) get more
attention than the popup switcjer that changes views, This is intended.
Sadly, the buttons are for advanced options that
will confuse newbies. As such, their spot at the
top of the window is way too prominent. The user
will wonder whether they need to do anything with
these when the installer opens.
The top of a window is the first place a user
will look at when a new window opens. That's why
mode indicators and toolbars with commonly used
commands go there. The bottom of the window is
the place where the user's eyes end up when she
has finished looking at a window's contents,
that's why the exit buttons ("OK", "Cancel") go
there. Both of these places aren't really good
spots for advanced options. I'd just put those in
a menu (though I'm not married to using "Window"
for that).
Post by Frederico MuñozIt is so simple that it might be used that way,
but it could also be used with different
options. However simple the package is the
interface presented must be the same. I'm
strictly speaking of Installer here, not of
alternative methods of installation that can use
Installer or it's bundles.
I don't think you're understanding me. The point
I'm making is that, since it would only be good
UI to have no UI on very simple installers, we
shouldn't optimize our installer UI for this
case. The Installer UI that is displayed by
default on opening a package should manage the
cases of complex installations only, however it
will only cover the common cases. Any odd cases
or hacker-ish uses of the installer by
knowledgeable people will require the use of the
Content Browser.
Post by Frederico MuñozYes, see above. We talked about it, I think it
is great, but is something that I will only work
upon after I have the "standard" Installer more
or less ready to be used. So in this view you
shouldn't expect special treatment for simple
packages. You can even assume that the package
contains an app that shouldn't need to be
packaged but it was nonetheless. The interface
we are talking about should be the same for
simple and complex packages, but that doesn't
mean we should assume that the simple ones won't
need any UI interaction.
I guess we have different levels of granularity here. I see:
SIMPLE
drop-install, or installer that doesn't require
options and is run at first launch. We don't need
a UI for this, except for maybe confirming to the
user that this stuff is to be installed at all --
the majority of packages
COMPLEX
Complex package structure for which we provide a
simplified UI that covers common cases, but which
may not allow all variations that advanced users
may want.
Note that the only thing I know that needs a GUI
(apart from deciding what to install and where)
is configuration. I.e. the stuff that goes in
"Preferences". And that needn't be done in the
Installer at all. The user will have to learn
where to change an app's preferences anyway, so
installation should simply put all needed
components in the right places and get the app
into a state which lets the user open it and open
its Preferences window. Saves us a lot of code
duplication, and the user only has to learn one
settings interface.
I hate it when I install an app, configure it
using its "Installation Wizard" and then later
come back and have to dig through its menus and
panels to find out where to find the first
setting in the installer in there. And I don't
want to re-run the installation wizard for fear
it will reset any of my settings.
You may have noticed that nobody ever went and
seriously complained about how simple Apple's
installer is. The only reasons why people use
different installers are when they want special
features like web download, deployment on MacOS 9
or support for some special compression scheme.
If you design your installer package carefully,
you will hardly need more than Apple's installer
provides.
Post by Frederico MuñozSee above. Even with the "automatic" methods you
mentioned a use could actually prefer to use the
installer Application for some reason (i.e. not
use Installer to do the automatic installation
but use the full app).
For what reason? And I don't understand that
sentence in the brackets... can you re-phrase?
Post by Frederico MuñozYou do raise a valid objection, I haven't
thought about meta packages (custom install
comes into play here) and the way to install
those is indeed hard to do with my current UI.
Well, Meta-Packages are probably the only
complex case an installer has to cope with. Most
other cases simply consist of copying files in
the right places and running some scripts. Is
there anything else an installer has to do that
needs user interaction at the level we are
talking right now?
Post by Frederico MuñozI guess this is where I provide a better description of my "bullet list"
view. The important thing about it is that it can do *everything* a tab view
can do. You can click one of the bullet-items and it will show that page (if
it isn't disabled). It could even give pages you already viewed a "visited"
color, like we have it for web links. The whole point of it is to encourage
just going through all the pages in sequence until you're finished, but to
get out of the way of power users who may know that the defaults are what
they need on two pages and let them advance directly to the third.
Wouldn't this also work the other way around?
Power users would be more likely to what to
change the defaults, while regular users would
justt go nex, nex, next, next, install
?
Isn't that what I wrote? Let me re-phrase and
annotate: "The whole point of it [the
bullet-list-view] is to encourage just going
through all the pages in sequence until you're
finished [if you are a regular user], *and* to
get out of the way *for power users*."
Post by Frederico MuñozOne thing I think is important is that the UI
should use the controls and presentation
commonly used in other apps. It must not
introduce a special way to present things.
Installer is by definition something that should
take advantage of the already known way that
things work in other apps. This is actually my
largest concern, as you will see below.
As I said above, there are moments where it is
necessary to invent your own controls. Usually,
it's a good idea to borrow metaphors from the
real world in those cases, though. Bullet lists
are one of those. But maybe it would be a less
fancy version where you just have a bullet
character and a regular, NSTableView-style
selection.
If you want an example from GUI history of a
similar case: MacOS versions prior to 8.0 didn't
have sliders. Some programmers just used
scrollers, which, while it used an existing
control, was totally wrong. Scrollers are
"miniature views of the whole document and my
view into it", sort of a stylized version of
Photoshop's "Navigator" palette. OTOH Sliders are
tools for specifying a numeric value from a range.
Post by Frederico MuñozI distinctly remember the fact that no option
should be accessible only trough controls in
certain contexts.
"in certain contexts" is the important point.
Post by Frederico MuñozThis is something that must indeed be clarified
since it is of interest not only for Installer
but all the apps.
Anybody taking notes for the GNUstep Human
Interface Guidelines? ;-) Anyway, the general
rule is simply that the user should be able to
see all commands available to them at a time.
This works for buttons in windows and menu items,
but shortcuts (like "shortcut menus" as Windows
calls them) and toolbar items don't count because
they are not obvious (or may be removed by the
user) and thus aren't always visible. That's the
main rationale here. To ensure visibility, they
should also be available from menus or permanent
buttons, or panels that can be called up in
response to those.
Does that help put the guideline in context?
Post by Frederico MuñozSo, the only case our GUI still needs to
cover is the case where you *need*
to specify some options. In that case, we shouldn't have need for more
options than the "Installation Type" pane in my example.
Again, I really want a generic solution that works equaly well in both cases.
I hope my descriptions above clarified why this
is really unnecessary. It's okay to use the
non-GUI parts of the installer for these cases,
but if all the installation involves is the
installation process itself, why present a GUI at
all?
If there are several choices, provide a sensible
default, and keep the really complicated stuff
hidden.
Post by Frederico MuñozI never done this, and I don't know if it is
something that is used in other apps. I prefer
using something already known to the user if
possible. Everything in a window seems weird to
me, I prefer your mockup.
It would pretty much look like any options
panel. I don't think this would really be
anything new. The disclosure of additional info
may be kinda new to GNUstep, but wouldn't be that
hard to get used to, and may actually make its
way into other apps.
Post by Frederico MuñozCorrect me if I'm omitting something, but the minimal installation info
Readme/License (short form, and a verbose version)
-----
Destination (sensible default for current system, button to change)
-----
Installation Type: (short blurb on default install, "Advanced" button)
-----
[Install]
The minimal info is what you see in the shots I
sent in the original mail, i.e. those you
mentioned plus Sizes and Platforms. Description
is also there, but the info is taken from the
Readme.
So, did I miss anything? I've obviously included
everything I understood in your screen shots,
though I may have changed some groupings. *I*
wouldn't be able to tell whether *I*'ve missed
something. That's why I'm asking you :-p
Post by Frederico MuñozThe Readme would be in a text field. The short field would be *forced* to
non-scrolling, and there would be strict guidelines on what kind of
information should go in there. It may have a button to show a more verbose
version for those that want it in a scrolling field...
Important point: I must assume that no specific
information particular to my Installer is given.
I must try to work with the information defined
in the spec.
What spec?
That said, remember that most of these packages
will be built for GNUstep, so I think you *can*
actually expect them to include info for your
installer that you need. If MacOS X porters have
a good Readme or Welcome file, they could
probably just use that for the short readme (or
an excerpt from that), but should we really throw
over board usability advances just to stay
compatible with OS X?
Post by Frederico MuñozYes, this for metapackages, normal packages can't be split.
Then I guess normal packages would fall under
"Simple" installation anyway. I mean, if you
can't split them, the only thing you can do is
install or uninstall. No need for a GUI there.
Post by Frederico MuñozDanger, Will Robinson! While "Upgrade" and
"Uninstall" are only needed when
you already have an installation, "Install" should stay available, for the
cases where you want to install on several
partitions or so (if Installer.app
supports that, that is).
Even if it doesn't, it should. You are right, it
should be there. This raises several problems
though, since the receipt will already exist.
How does OSX deal with this?
Are you saying we should allow to install
something twice? I'd say this is an error for any
users but advanced ones.
Post by Frederico MuñozI tend to lump these together into one item. Keep it short, sweet, and
informative. Too many readmes contain company philosophy, "thanks to" lists
and internal details, which isn't important for an installer. Instead, we'll
want "What does this app do?", "Are there any dangers?" (I.e. systems where
it's not recommended to install), "What rights do I have?". The latter would
essentially be a short Creative-Commons-Style summary of the license (+ a
button or link for calling up the full license).
The problem is that I can't control what people
put into them. The Welcome file should however
contain very basic info, since it is meant to be
displayed in OSX's Installer first view.
Well, this is open source. Everybody eventually
does what they want. However, you can write down
best practices and the motivation behind those
and hope that at least GNUstep developers will
heed them. It would be kind of funny if the
packages ported from MacOS X were the ones that
had bad usability. iTunes for Windows wouldn't be
that alone anymore :-)
Post by Frederico MuñozMy only standing points are that the
navigation/interaction should make use of
standard controls and usage patterns, it should
be possible to install the package without
navigating trough several screens... and that's
pretty much it. All the other things, including
the progress, I can agree with and make sense to
me.
Well, then I guess the
single-page-everything-together approach might be
the best way to take. I may make another mock-up
to illustrate this better, but now I really gotta
get some sleep.
--
Cheers,
M. Uli Kusterer
------------------------------------------------------------
"The Witnesses of TeachText are everywhere..."
http://www.zathras.de
