You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Erin Mulder <me...@alumni.princeton.edu> on 2005/07/02 09:33:43 UTC
Usability Notes: First Impressions
Congratulations on passing the TCK!
It sounds like usability is now a top concern, so here are some quick
first impressions based on the geronimo-1.0-169186 build. I approached
this as someone who had just heard the buzz about Geronimo and had
downloaded it to give it a try.
Many of these items are simple documentation or user feedback issues
that should be easy to fix. A lot of them are pretty minor, but taken
together, they make a difference.
1. It would be nice to have obvious startup.sh and startup.bat scripts
in the bin directory so that the user doesn't need to look at the README
file to figure out how to start the server. (I know java -jar
bin/server.jar isn't hard -- it's just not quite as brainless as a
script called "startup").
2. The README file should probably put the instructions for starting the
server ahead of the deployment instructions. (I think most people will
want to make sure Geronimo starts successfully before they invest time
in deployment or configuration.)
3. When first launching the server, it's hard to tell when startup is
complete. There are lots of pauses, and it's not clear whether there
will eventually be a "successful startup" message. This adds a bit of
uncertainty/confusion as you sit there and wonder whether it's done,
still going or broken. (It would actually be quite cool/unique to add
some sort of ascii progress bar like sftp and scp use.)
4. During startup, too much information is written to the console.
Ideally, it should display a "Server starting..." message, followed by
some sort of small progress indicator, followed by a "Server started
successfully!" message. Only errors, severe warnings, or truly useful
environment information should go in between. (A verbose switch could
be added to allow developers to load the server with the current chatty
log4j config.)
5. There's no sense of what to do next when first launching the server.
It would be nice to see something like "Server started successfully!
Visit the web console at http://localhost:8080/". It would also be
very nice to print out a quick table of the ports that the server is
listening on. Perhaps something like:
-----------------------------------------------------
> bin/startup.sh
Environment information:
JDK_HOME: /usr/lib/java
GERONIMO_BUILD: 1.0-169186
VERBOSE_LEVEL: quiet (use -verbose to change)
SERVER STARTING..................................
Now listening on:
Port 1234: JMS
Port 8080: HTTP
Port 8081: HTTPS
Port 9876: Foo
SERVER STARTED SUCCESSFULLY!
Browse to http://localhost:8080/ for web console
-----------------------------------------------------
6. I expected to find some sort of welcome page at
http://localhost:8080/ (to reassure me that installation & startup were
successful), but just got a 404. It would be nice for that URL to
present a welcome page that gives "quick start" instructions for
configuration, deployment, accessing the management console, etc. Links
to example apps and instructions on where to find their underlying code
would also be helpful.
7. Since there was no obvious management console, I followed the
instructions to enable the debug console. While doing this, I noticed that:
a. the README doesn't list username/password info next to the debug
console instructions. It's in a different section, and I didn't notice
it until after I was surprised by the "Username:" prompt.
b. Password input echoes to console (perhaps use shell/batch scripts
to work around this?)
c. In general, debug console deployment takes a long time with no feedback
8. Not immediately clear how to configure anything (data source, server
ports, application, etc.) There are no config directories that can be
browsed or grepped, no examples of data source configurations for common
databases, no sample applications, etc. At this point, you're pretty
much dumped into the main documentation page and need to comb through
articles and ebooks for more info. This is an easy point to give up
playing with Geronimo and go back to work on something else.
Anyway, that was the first 10-20 minutes. Now I need to work on porting
a few apps from JBoss and WebLogic to Geronimo. I'll keep a log of
first impressions as I go and will try to report back at some point.
Cheers,
Erin
PS. The tarball I downloaded included a NOTICE.txt that says Geronimo is
still in the incubator. This should probably be removed.
Re: Usability Notes: First Impressions
Posted by Erin Mulder <me...@alumni.princeton.edu>.
Dain Sundstrom wrote:
> Thanks Erin. This is just the kind of feedback we desperately need.
>
> If you have time, can you add these items to our bug/feature tracking
> system JIRA:
>
> http://issues.apache.org/jira/secure/BrowseProject.jspa?id=10220
>
> It looks like there are at least 8 fairly simple to implement new
> feature here, any of which would be a good opportunity for someone new
> to get involved in the project.
Just entered a bunch of them in JIRA.
It would be great if one of the JIRA project admins could add a way to
classify something as a usability issue (as opposed to a functionality
issue). That would allow for better prioritization among them, rather
than having to mark them all minor or trivial just because there are
workarounds.
Also, I'm not sure which "component" to select for issues relating to
the startup sequence. Should those go under "core"?
Cheers,
Erin
Re: Usability Notes: First Impressions
Posted by Dain Sundstrom <da...@iq80.com>.
Thanks Erin. This is just the kind of feedback we desperately need.
If you have time, can you add these items to our bug/feature tracking
system JIRA:
http://issues.apache.org/jira/secure/BrowseProject.jspa?id=10220
It looks like there are at least 8 fairly simple to implement new
feature here, any of which would be a good opportunity for someone
new to get involved in the project.
Again thanks for the feedback,
-dain
On Jul 2, 2005, at 12:33 AM, Erin Mulder wrote:
> Congratulations on passing the TCK!
>
> It sounds like usability is now a top concern, so here are some quick
> first impressions based on the geronimo-1.0-169186 build. I
> approached
> this as someone who had just heard the buzz about Geronimo and had
> downloaded it to give it a try.
>
> Many of these items are simple documentation or user feedback issues
> that should be easy to fix. A lot of them are pretty minor, but taken
> together, they make a difference.
>
> 1. It would be nice to have obvious startup.sh and startup.bat scripts
> in the bin directory so that the user doesn't need to look at the
> README
> file to figure out how to start the server. (I know java -jar
> bin/server.jar isn't hard -- it's just not quite as brainless as a
> script called "startup").
>
> 2. The README file should probably put the instructions for
> starting the
> server ahead of the deployment instructions. (I think most people
> will
> want to make sure Geronimo starts successfully before they invest time
> in deployment or configuration.)
>
> 3. When first launching the server, it's hard to tell when startup is
> complete. There are lots of pauses, and it's not clear whether there
> will eventually be a "successful startup" message. This adds a bit of
> uncertainty/confusion as you sit there and wonder whether it's done,
> still going or broken. (It would actually be quite cool/unique to add
> some sort of ascii progress bar like sftp and scp use.)
>
> 4. During startup, too much information is written to the console.
> Ideally, it should display a "Server starting..." message, followed by
> some sort of small progress indicator, followed by a "Server started
> successfully!" message. Only errors, severe warnings, or truly
> useful
> environment information should go in between. (A verbose switch could
> be added to allow developers to load the server with the current
> chatty
> log4j config.)
>
> 5. There's no sense of what to do next when first launching the
> server.
> It would be nice to see something like "Server started successfully!
> Visit the web console at http://localhost:8080/". It would also be
> very nice to print out a quick table of the ports that the server is
> listening on. Perhaps something like:
>
> -----------------------------------------------------
>
>> bin/startup.sh
>>
>
> Environment information:
> JDK_HOME: /usr/lib/java
> GERONIMO_BUILD: 1.0-169186
> VERBOSE_LEVEL: quiet (use -verbose to change)
>
> SERVER STARTING..................................
>
> Now listening on:
> Port 1234: JMS
> Port 8080: HTTP
> Port 8081: HTTPS
> Port 9876: Foo
>
> SERVER STARTED SUCCESSFULLY!
>
> Browse to http://localhost:8080/ for web console
> -----------------------------------------------------
>
> 6. I expected to find some sort of welcome page at
> http://localhost:8080/ (to reassure me that installation & startup
> were
> successful), but just got a 404. It would be nice for that URL to
> present a welcome page that gives "quick start" instructions for
> configuration, deployment, accessing the management console, etc.
> Links
> to example apps and instructions on where to find their underlying
> code
> would also be helpful.
>
> 7. Since there was no obvious management console, I followed the
> instructions to enable the debug console. While doing this, I
> noticed that:
> a. the README doesn't list username/password info next to the debug
> console instructions. It's in a different section, and I didn't
> notice
> it until after I was surprised by the "Username:" prompt.
> b. Password input echoes to console (perhaps use shell/batch scripts
> to work around this?)
> c. In general, debug console deployment takes a long time with no
> feedback
>
> 8. Not immediately clear how to configure anything (data source,
> server
> ports, application, etc.) There are no config directories that can be
> browsed or grepped, no examples of data source configurations for
> common
> databases, no sample applications, etc. At this point, you're pretty
> much dumped into the main documentation page and need to comb through
> articles and ebooks for more info. This is an easy point to give up
> playing with Geronimo and go back to work on something else.
>
> Anyway, that was the first 10-20 minutes. Now I need to work on
> porting
> a few apps from JBoss and WebLogic to Geronimo. I'll keep a log of
> first impressions as I go and will try to report back at some point.
>
> Cheers,
> Erin
>
> PS. The tarball I downloaded included a NOTICE.txt that says
> Geronimo is
> still in the incubator. This should probably be removed.
>
Re: WIKI Eclipse Deployment updated
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On 7/2/2005 6:23 AM, Stefan Schmidt wrote:
> Matt,
>
> I have added a view more steps demonstrating how to debug Geronimo
> within Eclipse following your tips on irc earlier.
>
> Could someone explain the synchronization issues and possible
> work-arounds?
>
> :Stefan
Stefan,
Please stop replying to an existing message to start a new thread. It
messes up those email readers who can track email threads.
Regards,
Alan
Re: WIKI Eclipse Deployment updated
Posted by David Jencks <da...@yahoo.com>.
On Jul 2, 2005, at 8:36 AM, Sachin Patel wrote:
> Stefan,
>
> There are two solutions I'm looking into..
>
> (1) There is an eclipse plugin, zipCreation then enables the output
> folder of a project to be jared up during the build. The jar can be
> specified to be created anywhere, in our case, the repository. Each
> time
> a change is made the project would build, and the repository would be
> updated with the new snapshot.
>
> (2) To configure the .classpath so that so that each project references
> other dependent projects in the workspace, rather then just the
> dependent snapshot jars in the repository. The dependency on the
> REPO would remain, the project references would simply be at a higher
> sort order on the build path. In this way, the projects would
> reference each other and there would be no need to create/update a
> snapshot.jar.
This is what the maven idea plugin (now) does. I recommend this
approach.
thanks
david jencks
>
> Both of these ways would be trivial to configure by hand for a few
> projects, but still very tedious for a large set of projects. So for
> both of these ways we would need a solution to automate the
> configuration of this, either though a command similar to maven
> m:eclipse, ant script or some other means.
>
> There is a possible third solution which I'm unfamiliar with and that
> is
> using the mavenide eclipse plugin, so that Maven is actually being
> run, rather then the Eclipse builder. I don't know the disadvantages
> and advantages of this approach, but it would be something to look
> into.
>
> Stefan Schmidt wrote:
>> Matt,
>> I have added a view more steps demonstrating how to debug Geronimo
>> within Eclipse following your tips on irc earlier.
>> Could someone explain the synchronization issues and possible
>> work-arounds?
>> :Stefan
>
Re: WIKI Eclipse Deployment updated
Posted by Sachin Patel <sp...@gmail.com>.
Stefan,
There are two solutions I'm looking into..
(1) There is an eclipse plugin, zipCreation then enables the output
folder of a project to be jared up during the build. The jar can be
specified to be created anywhere, in our case, the repository. Each time
a change is made the project would build, and the repository would be
updated with the new snapshot.
(2) To configure the .classpath so that so that each project references
other dependent projects in the workspace, rather then just the
dependent snapshot jars in the repository. The dependency on the
REPO would remain, the project references would simply be at a higher
sort order on the build path. In this way, the projects would reference
each other and there would be no need to create/update a snapshot.jar.
Both of these ways would be trivial to configure by hand for a few
projects, but still very tedious for a large set of projects. So for
both of these ways we would need a solution to automate the
configuration of this, either though a command similar to maven
m:eclipse, ant script or some other means.
There is a possible third solution which I'm unfamiliar with and that is
using the mavenide eclipse plugin, so that Maven is actually being run,
rather then the Eclipse builder. I don't know the disadvantages and
advantages of this approach, but it would be something to look into.
Stefan Schmidt wrote:
> Matt,
>
> I have added a view more steps demonstrating how to debug Geronimo
> within Eclipse following your tips on irc earlier.
>
> Could someone explain the synchronization issues and possible work-arounds?
>
> :Stefan
>
WIKI Eclipse Deployment updated
Posted by Stefan Schmidt <sc...@gmail.com>.
Matt,
I have added a view more steps demonstrating how to debug Geronimo
within Eclipse following your tips on irc earlier.
Could someone explain the synchronization issues and possible work-arounds?
:Stefan