>I really wish you wouldn't do that. Having separate manuals is
very
>useful for those who only use one tool such as the query browser.
>Combining documentation for QB with MT, Admin and WB seems
inappropriate
>here. I am also concerned that by packaging all these tools
together,
>that interdependencies will develop and users who just want one
tool
>will have to install them all, adding to the level of complexity
they
>must deal with just to get a certain level of functionality from
one
>tool.
Ever since the second GUI tool (Query Browser) hit the market there
has
been shared functionality between tools, for example the Table Editor.
Naturally, that common functionality requires installation of common
elements. Windows, you won't even notice this because the GUI suite
installer simply installs all tools by default. Linux, it's more
obvious: You have to install the common/shared elements prior to being
able to install the actual tools.
I believe it's logical to provide common/shared sections in the
documentation for common/shared functionality. Technically, we could
split out those common sections into separate XML files that we could
include a) in a common GUI tools manual, and b) in a manual for each
individual tool. So, from a technical standpoint, nothing would speak
against providing both kinds of manuals (combined and single).
From a usability standpoint, however, I believe it's better to put
the
sections that you'll read once and never again (if at all) first (or
maybe last), so that the contents that cover the individual programs
focus on how to use those programs, without telling over and over
again
how to install, configure, and start them (because that's very similar
across the tools, and actually differs more between supported
platforms
than between the tools themselves).
I would also like to expess my wish that no dependancies, between
the
programs of the package, would be developed.
Too late. ;-) There are already lots of dependencies between MySQL
Administrator and MySQL Query Browser. In my opinion, the
documentation
should reflect this, rather than hide it (like it currently does, or
did).
As far as the documentation is concerned I don't think it's that big
trouble to have all-in-one. I haven't used the new manual much yet.
However, in the past, I found no problem using, let's say
's
help, which is made of 10 sections (3 sections are general and 7
program-specific).
So much for KISS - Keep it Simple, Sam :)
of the frustrating things for new MySQL users/developers is the cost
of learning the tools. I'm glad that methods are being unified and that
at some point, it may be possible to use one tool for all these
functions. My concern is that the vast majority of those that actually
use MySQL in a corporate environment don't need administrative-level
access or understanding.
If the outlook involves combining the four tools, I would hope that
there would be a simple mode for those that just wanted to be able to
run queries without needing to worry about other parts of MySQL
interaction.
A big concern I have is the adoption rate of MySQL in corporate
environments. While MySQL is very popular, MySQL still has a reputation
as being the less scalable database between and MySQL.
also has a more professional reputation, being "more solid and reliable
under all circumstances." is also perceived to have better
tools. None of these perceptions is necessarily true, though if we do
nothing to address them directly, it's hard to make those perceptions
"go away." Discoverer is a classic example of why MySQL is
perceived as being more difficult to use than in a corporate
environment. We don't have a tool like it.
I know - this is getting somewhat off-topic, but there are times when I
wish we (as a group) would do better to stand up in the face of these
perceptions and find ways to eradicate them. Then, MySQL can compete
more evenly with and I think that will make a lot of people very
happy (myself included).
Kevin Benton
Perl/Bugzilla Developer/Administrator, Perforce SCM Administrator
AMD - ECSD Software Validation and Tools
The opinions stated in this communication do not necessarily reflect the
view of Advanced Micro Devices and have not been reviewed by management.
This communication may contain sensitive and/or confidential and/or
proprietary information. Distribution of such information is strictly
prohibited without prior consent of Advanced Micro Devices. This
communication is for the intended recipient(s) only. If you have
received this communication in error, please notify the sender, then
destroy any remaining copies of this communication.

Hi Kevin,

I really wish you wouldn't do that. Having separate manuals is
very
useful for those who only use one tool such as the query browser.
Combining documentation for QB with MT, Admin and WB seems
>inappropriate
here. I am also concerned that by packaging all these tools
together,
that interdependencies will develop and users who just want one
tool
will have to install them all, adding to the level of complexity
they
must deal with just to get a certain level of functionality from
one
tool.
>Ever since the second GUI tool (Query Browser) hit the market there
has
>been shared functionality between tools, for example the Table Editor.
>Naturally, that common functionality requires installation of common
>elements. Windows, you won't even notice this because the GUI suite
>installer simply installs all tools by default. Linux, it's more
>obvious: You have to install the common/shared elements prior to being
>able to install the actual tools.
>>
>I believe it's logical to provide common/shared sections in the
>documentation for common/shared functionality. Technically, we could
>split out those common sections into separate XML files that we could
>include a) in a common GUI tools manual, and b) in a manual for each
>individual tool. So, from a technical standpoint, nothing would speak
>against providing both kinds of manuals (combined and single).
>>
>From a usability standpoint, however, I believe it's better to put
the
>sections that you'll read once and never again (if at all) first (or
>maybe last), so that the contents that cover the individual programs
>focus on how to use those programs, without telling over and over
again
>how to install, configure, and start them (because that's very similar
>across the tools, and actually differs more between supported
platforms
>than between the tools themselves).
>>
I would also like to expess my wish that no dependancies, between
the
programs of the package, would be developed.
>Too late. ;-) There are already lots of dependencies between MySQL
>Administrator and MySQL Query Browser. In my opinion, the
documentation
>should reflect this, rather than hide it (like it currently does, or
did).
As far as the documentation is concerned I don't think it's that big
trouble to have all-in-one. I haven't used the new manual much yet.
However, in the past, I found no problem using, let's say
's
help, which is made of 10 sections (3 sections are general and 7
program-specific).

So much for KISS - Keep it Simple, Sam :)

of the frustrating things for new MySQL users/developers is the cost
of learning the tools. I'm glad that methods are being unified and that
at some point, it may be possible to use one tool for all these
functions. My concern is that the vast majority of those that actually
use MySQL in a corporate environment don't need administrative-level
access or understanding.

I agree, but I don't think this would imply to keep things apart
docs-wise. Actually, I believe it makes things simpler if we provide
information for, say, MySQL Query Browser, like this:
- Installation on Windows: see general section on Windows installation
- Installation on Linux: see general section on Windows installation
- Managing connections: see general section about storing and handling
connections
- etc.

course, all that information should just be one click away, and in
the same document.

Those general (tool-agnostic) sections would cover topics that one tends
to only need once (e.g. installation), or rarely (managing connections).
This, in turn, means the "actual" manual may focus on (tool-specific)
functionality.

If the outlook involves combining the four tools, I would hope that
there would be a simple mode for those that just wanted to be able to
run queries without needing to worry about other parts of MySQL
interaction.

That's certainly something to be discussed with the MySQL GUI team, not
with the guys who are "just" writing the docs. :)

A big concern I have is the adoption rate of MySQL in corporate
environments. While MySQL is very popular, MySQL still has a reputation
as being the less scalable database between and MySQL.
also has a more professional reputation, being "more solid and reliable
under all circumstances." is also perceived to have better
tools. None of these perceptions is necessarily true, though if we do
nothing to address them directly, it's hard to make those perceptions
"go away." Discoverer is a classic example of why MySQL is
perceived as being more difficult to use than in a corporate
environment. We don't have a tool like it.

Not yet. started a few years before we did. :) Regarding MySQL
GUI tools, the first one (Administrator) appeared in spring 2004 only.

I know - this is getting somewhat off-topic, but there are times when I
wish we (as a group) would do better to stand up in the face of these
perceptions and find ways to eradicate them. Then, MySQL can compete
more evenly with and I think that will make a lot of people very
happy (myself included).

I agree. Let's see what time will bring

Regards,

Stefan