[Fwd: Hudson concerns (from twitter/haqwin)]

[Kohsuke Kawaguchi]

Forwarded with the permission of the author.

This started in a Twitter conversation that Tyler spotted. He is a
professional UI engineer, and I find his feedbacks about UI very useful.

I wonder if there are other UI experts out there in the community who
might be willing to help us.

--
Kohsuke Kawaguchi
Sun Microsystems                   http://weblogs.java.net/blog/kohsuke/

First of, I have gotten lots of good feedback around Hudson from colleges in the java business. I'm from .NET but open to tools from other cummunities, especially since the tool isn't always tied to one technology.

That said, I have quite some experience with CC.NET (some good and some ugly...), TeamCity (crossplatform pro tool) and some with Cruise as well. Moreover, I focus most of my job on user experience and interaction design. That's why I made the comment. So now you got some background on me, on to some comments.

Site

Quite ok, a few pointers though, most that come to you wanna download and the menu to the left says download, but what you wanna do is supply the two links to the right on the left instead, in the menu. Now they are placed where most eyes don go on a site, upper right. 

Check this information on how users scan a page for information and you know where You have to put the important information: 

The wiki is good, and easy to find information on.

Installation

Easy installation well, yes, if you are used to hack around in command prompt. I have no problem with it but it's not as easy as point and click. I would say that for each OSt, you should support it in a way that are the norm for that OS, and in windows it's MSI or EXE file installation. Also, provide some basic setup questions at startup, like port and where the installation should be done. And why not give the option during installation to set up as a service directly.

Also you mention dependencies to other tools on the wiki, why not provide installations of these or if possibel supply the with Hudson windows installation.

Otherwise the installation experience was quite plesant.

    

The interface

Here is most of my concerns, there are som many details and quirks it's hard to get them in. 

• First of there are no consisten navigation, sometimes the menu, sometimes links in the main area and sometimes its easier to use the breadcrumbs. It's a mix between links and icons, that sometimes are buttons (but not obvious).
  
  For example the blue dot and the clock with a green arrow in Job listing seems like icons showing some status. but one can be clicked to trigger a build. How would the user know

• And other things are questions that to the user is irrelevant, for example when you change a name of a job. I already went into configruation and edited the name, why the question? I can understand that its quite a change in the backend if you need to move a lot of data. But to the user this is a minor thing, a very minor issue. And when it comes to name... using space in a job name breaks my builds, probably depending on the windows OS i suppose but it's nothing that I should worry about as a user.

• Setting up a new job - This as ok, but you could separate the steps even further, Basic build information, collecting the data for the build (VCS, artifacts from other builds, etc), execution and result collecting. For example, I really suggest you take a look at TeamCity for this, they have a view of up to 7 sven steps for configuration of a job.

Visuals

• The use of grids and boxes makes the view very cluttered. It's better use grouping and spacing and backgrounds to hold things together. 
• Make sure there is a consitency throughout the system. How do the user know the difference between triggering en action (build etc) or navigating. When clicking on a menu item, mark the menu item so its obvious where you are (think tabs)
• I need feed back, especially when things go wrong, a log out put that you show just burps it all up in the users view, why not use some smart triggers and emphasize with color or otherwise where the problem areas are. And you could have a quick and full view, showing only the error and 4-5 lines above and after. Often this provide very quick and easily identifiable information to solve a build problem. 

Unfortunately the only advantages this tool provide me as a .NET developer over CC.NET are two, easier configuration when setting up a new job and artifact collection important but not enough to shift me from TeamCity... :)

The feedback loop and problem solving in Hudson takes a bit too long with to much configuration (eports from testing and coverage etc) it wastes time in a project when you have to wait until the build fails and scan the full build log just o find that one test failed. 

I really think you could learn a lot from examining aspects of both TeamCity and Cruise both in interaction and visuals as in concepts around CI systems. Your tool has a lot of potential and a great community that are willing to spend time and resources getting it right.

Best regards // Håkan

---

Håkan Reis
User experience and .NET Consultant at Dotway AB
Øredev Program Committee
[phone]

Our conference || http://oredev.org - It's going to be great in 2009
My company  || http://dotway.se
My blog || http://blog.reis.se
My twitter || @haqwin

Mike Ditka  - "If God had wanted man to play soccer, he wouldn't have given us arms."

[tyler-3]

On Tue, 13 Oct 2009, Kohsuke Kawaguchi wrote:

> This started in a Twitter conversation that Tyler spotted. He is a
> professional UI engineer, and I find his feedbacks about UI very useful.
>
> I wonder if there are other UI experts out there in the community who
> might be willing to help us.


I'm glad you reached out to him, this is some really useful feedback,
more comments inline.


> That said, I have quite some experience with CC.NET (some good and some
> ugly...), TeamCity (crossplatform pro tool) and some with Cruise as well.
> Moreover, I focus most of my job on user experience and interaction design.
> That's why I made the comment. So now you got some background on me, on to
> some comments.

From my latest experience with CC.NET, TeamCity is likely a better place
to look to for reference of good UI (IMHO)


> *Installation*
>
> Easy installation well, yes, if you are used to hack around in command
> prompt. I have no problem with it but it's not as easy as point and click. I
> would say that for each OSt, you should support it in a way that are the
> norm for that OS, and in windows it's MSI or EXE file installation. Also,
> provide some basic setup questions at startup, like port and where the
> installation should be done. And why not give the option during installation
> to set up as a service directly.


Given the amount of "How do I use Hudson as a Windows service" questions
on users@, I think considering generating a "Hudson Installation Wizard"
that installs it as a service, as well as asking the user a few basic
configuration questions (as Hakan suggested).

> *The interface*
>
> Here is most of my concerns, there are som many details and quirks it's hard
> to get them in.
>
>    - First of there are no consisten navigation, sometimes the menu,
>    sometimes links in the main area and sometimes its easier to use the
>    breadcrumbs. It's a mix between links and icons, that sometimes are buttons
>    (but not obvious).
>
>    For example the blue dot and the clock with a green arrow in Job listing
>    seems like icons showing some status. but one can be clicked to trigger a
>    build. How would the user know
>

I cannot +1 this note enough, there are a number of places where we use
some amount of mixed concepts (sometimes icon, sometimes icon and text,
etc) as well as some layout inconsistencies between which portions of
the page are "actionable" versus "informative" (the view pages come to
mind, as well as the project page)

>
>    - Setting up a new job - This as ok, but you could separate the steps
>    even further, Basic build information, collecting the data for the build
>    (VCS, artifacts from other builds, etc), execution and result collecting.
>    For example, I really suggest you take a look at TeamCity for this, they
>    have a view of up to 7 sven steps for configuration of a job.

I wonder if a step-by-step view would be less overwhelming to the
average user; i.e. take the segments we already denote with a long
horizontal line, and break them up into "views" such as: "Overview", "SCM",
"Building", "Archival", "Notification", "Advanced". I would imagine a
tabbed view across the top of the configure page would be sufficient to
allow power users to jump to a step that they prefer, but for the 80%
of users configuring (particularly a new job) the flow would be:

  1. Overview (fill in project name, description, etc) *click Next*
  2. SCM (fill in SCM details) *click Next*
  3. Building (fill in build execution steps, build environment) *click Next*
  4. Archival *click Next*
  5. Notification *click Save*

I concede that there are more clicks involved here, but presenting a
"configure progress bar" at the top, and breaking the process into
logical segments I believe to be easier to digest than a long list of
options (which we can likely still allow users to configure via)


> *Visuals*
>
>    - The use of grids and boxes makes the view very cluttered. It's better
>    use grouping and spacing and backgrounds to hold things together.
>    - Make sure there is a consitency throughout the system. How do the user
>    know the difference between triggering en action (build etc) or navigating.
>    When clicking on a menu item, mark the menu item so its obvious where you
>    are (think tabs)

+1
 
>    - I need feed back, especially when things go wrong, a log out put that
>    you show just burps it all up in the users view, why not use some smart
>    triggers and emphasize with color or otherwise where the problem areas are.
>    And you could have a quick and full view, showing only the error and 4-5
>    lines above and after. Often this provide very quick
>    and easily identifiable information to solve a build problem.

+1

>
> Unfortunately the only advantages this tool provide me as a *.NET develope*r
> over CC.NET are two, easier configuration when setting up a new job and
> artifact collection important but not enough to shift me from TeamCity... :)

Automating/detection of artifacts might be an interesting addition to
Hudson, not sure if it necessary fits into the guise of UI improvements,
but certainly UX

Cheers,
-R. Tyler Ballance

[Erik Ramfelt]

My comments inline:

On Wed, Oct 14, 2009 at 00:14, Kohsuke Kawaguchi
<[hidden email]> wrote:

>
> Forwarded with the permission of the author.
>
> This started in a Twitter conversation that Tyler spotted. He is a
> professional UI engineer, and I find his feedbacks about UI very useful.
>
> I wonder if there are other UI experts out there in the community who
> might be willing to help us.
>
> --
> Kohsuke Kawaguchi
> Sun Microsystems                   http://weblogs.java.net/blog/kohsuke/
>
> First of, I have gotten lots of good feedback around Hudson from colleges in the java business. I'm from .NET but open to tools from other cummunities, especially since the tool isn't always tied to one technology.
> That said, I have quite some experience with CC.NET (some good and some ugly...), TeamCity (crossplatform pro tool) and some with Cruise as well. Moreover, I focus most of my job on user experience and interaction design. That's why I made the comment. So now you got some background on me, on to some comments.
>
> Site
> Quite ok, a few pointers though, most that come to you wanna download and the menu to the left says download, but what you wanna do is supply the two links to the right on the left instead, in the menu. Now they are placed where most eyes don go on a site, upper right.
> Check this information on how users scan a page for information and you know where You have to put the important information:
> The wiki is good, and easy to find information on.
>
> Installation
> Easy installation well, yes, if you are used to hack around in command prompt. I have no problem with it but it's not as easy as point and click. I would say that for each OSt, you should support it in a way that are the norm for that OS, and in windows it's MSI or EXE file installation. Also, provide some basic setup questions at startup, like port and where the installation should be done. And why not give the option during installation to set up as a service directly.

I think the JNLP web link should be posted on top the "Download"
links, so the user can quickly start to use Hudson. I dont think there
is a need for a separate exe/msi file as Hudson can already install
itself as a service on Windows. But then again, we have separate
installations for redhat, debian, solaris and so on. Perhaps an
exe/msi that downloads the latest JRE if it isnt already installed.
(either launch4j or nsis can do this)

One thing I miss through the UI, is to set the http port that Hudson
is using. To change it on Windows, you have to hack the xml file or
specify it on the command line.  Can't this be stored in the main
config file and only be shown if Hudson is started through the
winstone container?


> Also you mention dependencies to other tools on the wiki, why not provide installations of these or if possibel supply the with Hudson windows installation.

The auto installation that exists for JDK, Maven and ant already does
this. But still there are more tools that needs to be added to the
auto installation. Perhaps someone with knowledge could add a page
about adding auto installation to the wiki, so plugins such as NAnt,
NUnit, etc can easily add it.

> Otherwise the installation experience was quite plesant.
>
> The interface
> Here is most of my concerns, there are som many details and quirks it's hard to get them in.
>
> First of there are no consisten navigation, sometimes the menu, sometimes links in the main area and sometimes its easier to use the breadcrumbs. It's a mix between links and icons, that sometimes are buttons (but not obvious).
>
> For example the blue dot and the clock with a green arrow in Job listing seems like icons showing some status. but one can be clicked to trigger a build. How would the user know
>
> And other things are questions that to the user is irrelevant, for example when you change a name of a job. I already went into configruation and edited the name, why the question? I can understand that its quite a change in the backend if you need to move a lot of data. But to the user this is a minor thing, a very minor issue. And when it comes to name... using space in a job name breaks my builds, probably depending on the windows OS i suppose but it's nothing that I should worry about as a user.
>
> Setting up a new job - This as ok, but you could separate the steps even further, Basic build information, collecting the data for the build (VCS, artifacts from other builds, etc), execution and result collecting. For example, I really suggest you take a look at TeamCity for this, they have a view of up to 7 sven steps for configuration of a job.

+1 on this. It will make configuration quicker, as currently a job's
configuration page takes longer to load as you have more plugins
installed. If they were separated through tabs as suggested by Tyler,
it would also be possible to do a wizard thing.


> Visuals
>
> The use of grids and boxes makes the view very cluttered. It's better use grouping and spacing and backgrounds to hold things together.
> Make sure there is a consitency throughout the system. How do the user know the difference between triggering en action (build etc) or navigating. When clicking on a menu item, mark the menu item so its obvious where you are (think tabs)
> I need feed back, especially when things go wrong, a log out put that you show just burps it all up in the users view, why not use some smart triggers and emphasize with color or otherwise where the problem areas are. And you could have a quick and full view, showing only the error and 4-5 lines above and after. Often this provide very quick and easily identifiable information to solve a build problem.

Perhaps this separating of the build steps (in configuration) could
make it possible to do builds that only executes the reporting steps.
Today it takes too much time tweaking your configuration as you have
to do full builds to test a new report. I would love to only run the
post actions at one point without updating the SCM and building all
files.

> Unfortunately the only advantages this tool provide me as a .NET developer over CC.NET are two, easier configuration when setting up a new job and artifact collection important but not enough to shift me from TeamCity... :)
> The feedback loop and problem solving in Hudson takes a bit too long with to much configuration (eports from testing and coverage etc) it wastes time in a project when you have to wait until the build fails and scan the full build log just o find that one test failed.
> I really think you could learn a lot from examining aspects of both TeamCity and Cruise both in interaction and visuals as in concepts around CI systems. Your tool has a lot of potential and a great community that are willing to spend time and resources getting it right.
> Best regards // Håkan
> ---
> Håkan Reis
> User experience and .NET Consultant at Dotway AB
> Øredev Program Committee
> [phone]
>
> Our conference || http://oredev.org - It's going to be great in 2009
> My company  || http://dotway.se
> My blog || http://blog.reis.se
> My twitter || @haqwin
>
> Mike Ditka  - "If God had wanted man to play soccer, he wouldn't have given us arms."
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Andrew Bayer]

I'm not going to bother with inline comments, since this is getting long enough as is. =) Really, I'm just chiming in with more support for a tabbed/wizard sort of interface for job configuration especially (but probably for global configuration as well) - that'd be a big improvement.

A.

On Wed, Oct 14, 2009 at 2:15 AM, Erik Ramfelt <[hidden email]> wrote:

My comments inline:

On Wed, Oct 14, 2009 at 00:14, Kohsuke Kawaguchi
<[hidden email]> wrote:
>
> Forwarded with the permission of the author.
>
> This started in a Twitter conversation that Tyler spotted. He is a
> professional UI engineer, and I find his feedbacks about UI very useful.
>
> I wonder if there are other UI experts out there in the community who
> might be willing to help us.
>
> --
> Kohsuke Kawaguchi
> Sun Microsystems                   http://weblogs.java.net/blog/kohsuke/
>

> First of, I have gotten lots of good feedback around Hudson from colleges in the java business. I'm from .NET but open to tools from other cummunities, especially since the tool isn't always tied to one technology.

> That said, I have quite some experience with CC.NET (some good and some ugly...), TeamCity (crossplatform pro tool) and some with Cruise as well. Moreover, I focus most of my job on user experience and interaction design. That's why I made the comment. So now you got some background on me, on to some comments.
>

> Site
> Quite ok, a few pointers though, most that come to you wanna download and the menu to the left says download, but what you wanna do is supply the two links to the right on the left instead, in the menu. Now they are placed where most eyes don go on a site, upper right.
> Check this information on how users scan a page for information and you know where You have to put the important information:
> The wiki is good, and easy to find information on.

>
> Installation
> Easy installation well, yes, if you are used to hack around in command prompt. I have no problem with it but it's not as easy as point and click. I would say that for each OSt, you should support it in a way that are the norm for that OS, and in windows it's MSI or EXE file installation. Also, provide some basic setup questions at startup, like port and where the installation should be done. And why not give the option during installation to set up as a service directly.

I think the JNLP web link should be posted on top the "Download"
links, so the user can quickly start to use Hudson. I dont think there
is a need for a separate exe/msi file as Hudson can already install
itself as a service on Windows. But then again, we have separate
installations for redhat, debian, solaris and so on. Perhaps an
exe/msi that downloads the latest JRE if it isnt already installed.
(either launch4j or nsis can do this)

One thing I miss through the UI, is to set the http port that Hudson
is using. To change it on Windows, you have to hack the xml file or
specify it on the command line.  Can't this be stored in the main
config file and only be shown if Hudson is started through the
winstone container?


> Also you mention dependencies to other tools on the wiki, why not provide installations of these or if possibel supply the with Hudson windows installation.

The auto installation that exists for JDK, Maven and ant already does
this. But still there are more tools that needs to be added to the
auto installation. Perhaps someone with knowledge could add a page
about adding auto installation to the wiki, so plugins such as NAnt,
NUnit, etc can easily add it.


> Otherwise the installation experience was quite plesant.

>
> The interface
> Here is most of my concerns, there are som many details and quirks it's hard to get them in.
>
> First of there are no consisten navigation, sometimes the menu, sometimes links in the main area and sometimes its easier to use the breadcrumbs. It's a mix between links and icons, that sometimes are buttons (but not obvious).
>
> For example the blue dot and the clock with a green arrow in Job listing seems like icons showing some status. but one can be clicked to trigger a build. How would the user know
>

> And other things are questions that to the user is irrelevant, for example when you change a name of a job. I already went into configruation and edited the name, why the question? I can understand that its quite a change in the backend if you need to move a lot of data. But to the user this is a minor thing, a very minor issue. And when it comes to name... using space in a job name breaks my builds, probably depending on the windows OS i suppose but it's nothing that I should worry about as a user.

>
> Setting up a new job - This as ok, but you could separate the steps even further, Basic build information, collecting the data for the build (VCS, artifacts from other builds, etc), execution and result collecting. For example, I really suggest you take a look at TeamCity for this, they have a view of up to 7 sven steps for configuration of a job.

+1 on this. It will make configuration quicker, as currently a job's
configuration page takes longer to load as you have more plugins
installed. If they were separated through tabs as suggested by Tyler,
it would also be possible to do a wizard thing.

> Visuals
>
> The use of grids and boxes makes the view very cluttered. It's better use grouping and spacing and backgrounds to hold things together.
> Make sure there is a consitency throughout the system. How do the user know the difference between triggering en action (build etc) or navigating. When clicking on a menu item, mark the menu item so its obvious where you are (think tabs)

> I need feed back, especially when things go wrong, a log out put that you show just burps it all up in the users view, why not use some smart triggers and emphasize with color or otherwise where the problem areas are. And you could have a quick and full view, showing only the error and 4-5 lines above and after. Often this provide very quick and easily identifiable information to solve a build problem.

Perhaps this separating of the build steps (in configuration) could
make it possible to do builds that only executes the reporting steps.
Today it takes too much time tweaking your configuration as you have
to do full builds to test a new report. I would love to only run the
post actions at one point without updating the SCM and building all
files.


> Unfortunately the only advantages this tool provide me as a .NET developer over CC.NET are two, easier configuration when setting up a new job and artifact collection important but not enough to shift me from TeamCity... :)
> The feedback loop and problem solving in Hudson takes a bit too long with to much configuration (eports from testing and coverage etc) it wastes time in a project when you have to wait until the build fails and scan the full build log just o find that one test failed.
> I really think you could learn a lot from examining aspects of both TeamCity and Cruise both in interaction and visuals as in concepts around CI systems. Your tool has a lot of potential and a great community that are willing to spend time and resources getting it right.
> Best regards // Håkan
> ---
> Håkan Reis
> User experience and .NET Consultant at Dotway AB
> Øredev Program Committee
> [phone]
>
> Our conference || http://oredev.org - It's going to be great in 2009
> My company  || http://dotway.se
> My blog || http://blog.reis.se
> My twitter || @haqwin
>
> Mike Ditka  - "If God had wanted man to play soccer, he wouldn't have given us arms."
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Aleksandar Kostadinov]

Erik Ramfelt wrote, On 10/14/2009 12:15 PM (EEST):

>> The interface
>> Here is most of my concerns, there are som many details and quirks it's hard to get them in.
>>
>> First of there are no consisten navigation, sometimes the menu, sometimes links in the main area and sometimes its easier to use the breadcrumbs. It's a mix between links and icons, that sometimes are buttons (but not obvious).
>>
>> For example the blue dot and the clock with a green arrow in Job listing seems like icons showing some status. but one can be clicked to trigger a build. How would the user know
>>
>> And other things are questions that to the user is irrelevant, for example when you change a name of a job. I already went into configruation and edited the name, why the question? I can understand that its quite a change in the backend if you need to move a lot of data. But to the user this is a minor thing, a very minor issue. And when it comes to name... using space in a job name breaks my builds, probably depending on the windows OS i suppose but it's nothing that I should worry about as a user.
>>
>> Setting up a new job - This as ok, but you could separate the steps even further, Basic build information, collecting the data for the build (VCS, artifacts from other builds, etc), execution and result collecting. For example, I really suggest you take a look at TeamCity for this, they have a view of up to 7 sven steps for configuration of a job.
>
> +1 on this. It will make configuration quicker, as currently a job's
> configuration page takes longer to load as you have more plugins
> installed. If they were separated through tabs as suggested by Tyler,
> it would also be possible to do a wizard thing.

-1, please if you want to make the configuration a clicking disaster,
leave a tab named "all" so one can look at all the options on one page
like now.
Another alternative is go into the current direction to have sections of
the configuration hidden and get expanded on a click. That could keep it
simple and you don't have to move mouse to some obscure part of the
screen to switch tabs.

>> Visuals
>>
>> The use of grids and boxes makes the view very cluttered. It's better use grouping and spacing and backgrounds to hold things together.
>> Make sure there is a consitency throughout the system. How do the user know the difference between triggering en action (build etc) or navigating. When clicking on a menu item, mark the menu item so its obvious where you are (think tabs)
>> I need feed back, especially when things go wrong, a log out put that you show just burps it all up in the users view, why not use some smart triggers and emphasize with color or otherwise where the problem areas are. And you could have a quick and full view, showing only the error and 4-5 lines above and after. Often this provide very quick and easily identifiable information to solve a build problem.
>
> Perhaps this separating of the build steps (in configuration) could
> make it possible to do builds that only executes the reporting steps.
> Today it takes too much time tweaking your configuration as you have
> to do full builds to test a new report. I would love to only run the
> post actions at one point without updating the SCM and building all
> files.

+1 for the execution of particular phase of the build.

wrt the rest: I always thought it is easy to navigate and understand
what hudson does. Having just a few links in the menu you have:
* all options in one place
* from first try you see what it does and know for the next time.

As well I see a great consistency, for example when you see a bar, you
can click on it and see build console. As well one can easily navigate
from first use. When you get used to standard navigation, you notice the
icon that can make your job get built and use it instead.
What's the problem?

Please don't remove links! :) Having multiple ways to achieve something
is good rather than bad. Believe me I'm fed up by *consistent* tools.
Being one click from what you want to look at has always been a great
feature of hudson. Actually I wonder if it will be possible to go to the
project's page when you see a project is building on an executor. Now
one can click on the build name/number and go to the build page. What if
only the number links to the build page and the rest to the project's page?


And btw, ease of use/configuration made us switch to hudson from cc more
than any other feature.

Just thought again that hudson is actually for developers and not random
users. Although to be a developer doesn't at all guarantee you are not
stupid, that are usually not people that expect to see a wizard for
configuring the simplest thing in the system. And hudson help for the
features (just next to the feature configuraiton) is so good that I
can't see how a wizard can help...
As well users of hudson usually use it continuously so easily achieving
the end goal is more important than having a wizard for everything. I
have only one program that I prefer using the wizard when working with,
because its interface is insane. The wizard also but I got used to it :)

Just my thoughts.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

[Kohsuke Kawaguchi]

Erik Ramfelt wrote:

> My comments inline:
>
> On Wed, Oct 14, 2009 at 00:14, Kohsuke Kawaguchi
> <[hidden email]> wrote:
>>
>> Forwarded with the permission of the author.
>>
>> This started in a Twitter conversation that Tyler spotted. He is a
>> professional UI engineer, and I find his feedbacks about UI very useful.
>>
>> I wonder if there are other UI experts out there in the community who
>> might be willing to help us.
>>
>> --
>> Kohsuke Kawaguchi
>> Sun Microsystems � � � � � � � � � http://weblogs.java.net/blog/kohsuke/
>>
>> First of, I have gotten�lots of good feedback around Hudson from colleges in the java business. I'm from .NET but open to tools from other cummunities, especially since the tool isn't always tied to one technology.
>> That said, I have quite some experience with CC.NET (some good and some ugly...), TeamCity (crossplatform pro tool) and some with Cruise as well. Moreover, I focus most of my job on user experience and interaction design. That's why I made the comment.�So now you got some background on me, on to some comments.
>>
>> Site
>> Quite ok, a few pointers though, most that come to you wanna download and the menu to the left says download, but what you wanna do is supply the two links to the right on the left instead, in the menu. Now they are placed where most eyes don go on a site, upper right.
>> Check this information on how users scan a page for information and you know where You have to put the important information:
>> The wiki is good, and easy to find information on.
>>
>> Installation
>> Easy installation well, yes, if you are used to hack around in command prompt. I have no problem with it but it's not as easy as point and click. I would say that for each OSt, you should support it in a way that are the norm for that OS, and in windows it's MSI or EXE file installation. Also, provide some basic setup questions at startup, like port and where the installation should be done. And why not give the option during installation to set up as a service directly.
>
> I think the JNLP web link should be posted on top the "Download"
> links, so the user can quickly start to use Hudson. I dont think there

Another person told me the same thing --- I'll add it.

> is a need for a separate exe/msi file as Hudson can already install
> itself as a service on Windows. But then again, we have separate
> installations for redhat, debian, solaris and so on. Perhaps an
> exe/msi that downloads the latest JRE if it isnt already installed.
> (either launch4j or nsis can do this)

It's been too long since I was a real Windows guy, so I no longer claim
to understand the Windows mentality. But I took his comment to mean that
Windows guys expect msi/exe for a point-and-click experience.

It also made sense to me that if you just do .NET development and don't
know anything about Java, you probably wouldn't know how to handle a war
file.

Unfortunately, JRE doesn't provide a MSM, so bundling JRE in an
installer is more painful than it should be.


> One thing I miss through the UI, is to set the http port that Hudson
> is using. To change it on Windows, you have to hack the xml file or
> specify it on the command line.  Can't this be stored in the main
> config file and only be shown if Hudson is started through the
> winstone container?

I agree. This is also a problem on other platforms, as people don't
necessarily know where they are configured.

I've been meaning to provide this capability, but haven't done so yet.


>> Also you mention dependencies to other tools on the wiki, why not provide installations of these or if possibel supply the with Hudson windows installation.
>
> The auto installation that exists for JDK, Maven and ant already does
> this. But still there are more tools that needs to be added to the
> auto installation. Perhaps someone with knowledge could add a page
> about adding auto installation to the wiki, so plugins such as NAnt,
> NUnit, etc can easily add it.

Yes. I promised to provide a write-up and failed to deliver so far.

>> Otherwise�the installation experience was quite plesant.
>>
>> The interface
>> Here is most of my concerns, there are som many details and quirks it's hard to get them in.
>>
>> First of there are no consisten navigation, sometimes the menu, sometimes links in the main area and sometimes its easier to use the breadcrumbs. It's a mix between links and icons, that sometimes are buttons (but not obvious).
>>
>> For example the blue dot and the clock with a green arrow in Job listing seems like icons showing some status. but one can be clicked to trigger a build. How would the user know
>>
>> And other things are questions that to the user is irrelevant, for example when you change a name of a job. I already went into configruation and edited the name, why the question? I can understand that its quite a change in the backend if you need to move a lot of data. But to the user this is a minor thing, a very minor issue. And when it comes to name... using space in a job name breaks my builds, probably depending on the windows OS i suppose but it's nothing that I should worry about as a user.
>>
>> Setting up a new job - This as ok, but you could separate the steps even further, Basic build information, collecting the data for the build (VCS, artifacts from other builds, etc), execution and result collecting. For example, I really suggest you take a look at TeamCity for this, they have a view of up to 7 sven steps for configuration of a job.
>
> +1 on this. It will make configuration quicker, as currently a job's
> configuration page takes longer to load as you have more plugins
> installed. If they were separated through tabs as suggested by Tyler,
> it would also be possible to do a wizard thing.

I suspect there's some kind of bug here, as it seems disproportionately
slow compared to other activities. I wonder if anyone is willing to
profile it.

>> Visuals
>>
>> The use of grids and boxes makes the view very cluttered. It's better use grouping and spacing and backgrounds to hold things together.
>> Make sure there is a consitency throughout the system. How do the user know the difference between triggering en action (build etc) or navigating. When clicking on a menu item, mark the menu item so its obvious where you are (think tabs)
>> I need feed back, especially when things go wrong, a log out put that you show just burps it all up in the users view, why not use some smart triggers and emphasize with color or otherwise where the problem areas are. And you could have a quick and full view, showing only the error and 4-5 lines above and after. Often this provide very quick and�easily�identifiable�information to solve a build problem.
>
> Perhaps this separating of the build steps (in configuration) could
> make it possible to do builds that only executes the reporting steps.
> Today it takes too much time tweaking your configuration as you have
> to do full builds to test a new report. I would love to only run the
> post actions at one point without updating the SCM and building all
> files.
>
>
>> Unfortunately the only advantages this tool provide me as a .NET developer over CC.NET are two, easier configuration when setting up a new job and artifact collection important but not enough to shift me from TeamCity... :)
>> The feedback loop and problem solving in Hudson takes a bit too long with to much configuration (eports from testing and coverage etc) it wastes time in a project when you have to wait until the build fails and scan the full build log just o find that one test failed.
>> I really think you could learn a lot from examining aspects of both TeamCity and Cruise both in interaction and visuals as in concepts around CI systems. Your tool has a lot of potential and a great community that are willing to spend time and resources getting it right.
>> Best regards // H�kan

--
Kohsuke Kawaguchi
Sun Microsystems                   http://weblogs.java.net/blog/kohsuke/

[stephenconnolly]

2009/10/24 Kohsuke Kawaguchi <[hidden email]>

Erik Ramfelt wrote:
> My comments inline:
>
> On Wed, Oct 14, 2009 at 00:14, Kohsuke Kawaguchi
> <[hidden email]> wrote:
>>
>> Forwarded with the permission of the author.
>>
>> This started in a Twitter conversation that Tyler spotted. He is a
>> professional UI engineer, and I find his feedbacks about UI very useful.
>>
>> I wonder if there are other UI experts out there in the community who
>> might be willing to help us.
>>
>> --
>> Kohsuke Kawaguchi

>> Sun Microsystems � � � � � � � � � http://weblogs.java.net/blog/kohsuke/
>>
>> First of, I have gotten�lots of good feedback around Hudson from colleges in the java business. I'm from .NET but open to tools from other cummunities, especially since the tool isn't always tied to one technology.
>> That said, I have quite some experience with CC.NET (some good and some ugly...), TeamCity (crossplatform pro tool) and some with Cruise as well. Moreover, I focus most of my job on user experience and interaction design. That's why I made the comment.�So now you got some background on me, on to some comments.

>>
>> Site
>> Quite ok, a few pointers though, most that come to you wanna download and the menu to the left says download, but what you wanna do is supply the two links to the right on the left instead, in the menu. Now they are placed where most eyes don go on a site, upper right.
>> Check this information on how users scan a page for information and you know where You have to put the important information:
>> The wiki is good, and easy to find information on.
>>
>> Installation
>> Easy installation well, yes, if you are used to hack around in command prompt. I have no problem with it but it's not as easy as point and click. I would say that for each OSt, you should support it in a way that are the norm for that OS, and in windows it's MSI or EXE file installation. Also, provide some basic setup questions at startup, like port and where the installation should be done. And why not give the option during installation to set up as a service directly.
>
> I think the JNLP web link should be posted on top the "Download"
> links, so the user can quickly start to use Hudson. I dont think there

Another person told me the same thing --- I'll add it.

> is a need for a separate exe/msi file as Hudson can already install
> itself as a service on Windows. But then again, we have separate
> installations for redhat, debian, solaris and so on. Perhaps an
> exe/msi that downloads the latest JRE if it isnt already installed.
> (either launch4j or nsis can do this)

It's been too long since I was a real Windows guy, so I no longer claim
to understand the Windows mentality. But I took his comment to mean that
Windows guys expect msi/exe for a point-and-click experience.

It also made sense to me that if you just do .NET development and don't
know anything about Java, you probably wouldn't know how to handle a war
file.

Unfortunately, JRE doesn't provide a MSM, so bundling JRE in an
installer is more painful than it should be.

AFAIK, the sun license would not prevent us shipping a private JRE in a windows installer, e.g.

we'd have sth like

c:\program files
    \hudson
       \jre
         \bin
         etc
       \bin
         hudson-service.exe
       \lib
         hudson.war

with a private jre, you don't have to worry about registry hooks, and it would simplify issues on windows as we'd know that they were using a specific java version

> One thing I miss through the UI, is to set the http port that Hudson
> is using. To change it on Windows, you have to hack the xml file or
> specify it on the command line.  Can't this be stored in the main
> config file and only be shown if Hudson is started through the
> winstone container?

I agree. This is also a problem on other platforms, as people don't
necessarily know where they are configured.

I've been meaning to provide this capability, but haven't done so yet.

>> Also you mention dependencies to other tools on the wiki, why not provide installations of these or if possibel supply the with Hudson windows installation.
>
> The auto installation that exists for JDK, Maven and ant already does
> this. But still there are more tools that needs to be added to the
> auto installation. Perhaps someone with knowledge could add a page
> about adding auto installation to the wiki, so plugins such as NAnt,
> NUnit, etc can easily add it.

Yes. I promised to provide a write-up and failed to deliver so far.


>> Otherwise�the installation experience was quite plesant.

>>
>> The interface
>> Here is most of my concerns, there are som many details and quirks it's hard to get them in.
>>
>> First of there are no consisten navigation, sometimes the menu, sometimes links in the main area and sometimes its easier to use the breadcrumbs. It's a mix between links and icons, that sometimes are buttons (but not obvious).
>>
>> For example the blue dot and the clock with a green arrow in Job listing seems like icons showing some status. but one can be clicked to trigger a build. How would the user know
>>
>> And other things are questions that to the user is irrelevant, for example when you change a name of a job. I already went into configruation and edited the name, why the question? I can understand that its quite a change in the backend if you need to move a lot of data. But to the user this is a minor thing, a very minor issue. And when it comes to name... using space in a job name breaks my builds, probably depending on the windows OS i suppose but it's nothing that I should worry about as a user.
>>
>> Setting up a new job - This as ok, but you could separate the steps even further, Basic build information, collecting the data for the build (VCS, artifacts from other builds, etc), execution and result collecting. For example, I really suggest you take a look at TeamCity for this, they have a view of up to 7 sven steps for configuration of a job.
>
> +1 on this. It will make configuration quicker, as currently a job's
> configuration page takes longer to load as you have more plugins
> installed. If they were separated through tabs as suggested by Tyler,
> it would also be possible to do a wizard thing.

I suspect there's some kind of bug here, as it seems disproportionately
slow compared to other activities. I wonder if anyone is willing to
profile it.

>> Visuals
>>
>> The use of grids and boxes makes the view very cluttered. It's better use grouping and spacing and backgrounds to hold things together.
>> Make sure there is a consitency throughout the system. How do the user know the difference between triggering en action (build etc) or navigating. When clicking on a menu item, mark the menu item so its obvious where you are (think tabs)

>> I need feed back, especially when things go wrong, a log out put that you show just burps it all up in the users view, why not use some smart triggers and emphasize with color or otherwise where the problem areas are. And you could have a quick and full view, showing only the error and 4-5 lines above and after. Often this provide very quick and�easily�identifiable�information to solve a build problem.

>
> Perhaps this separating of the build steps (in configuration) could
> make it possible to do builds that only executes the reporting steps.
> Today it takes too much time tweaking your configuration as you have
> to do full builds to test a new report. I would love to only run the
> post actions at one point without updating the SCM and building all
> files.
>
>
>> Unfortunately the only advantages this tool provide me as a .NET developer over CC.NET are two, easier configuration when setting up a new job and artifact collection important but not enough to shift me from TeamCity... :)
>> The feedback loop and problem solving in Hudson takes a bit too long with to much configuration (eports from testing and coverage etc) it wastes time in a project when you have to wait until the build fails and scan the full build log just o find that one test failed.
>> I really think you could learn a lot from examining aspects of both TeamCity and Cruise both in interaction and visuals as in concepts around CI systems. Your tool has a lot of potential and a great community that are willing to spend time and resources getting it right.

>> Best regards // H�kan

--

Kohsuke Kawaguchi
Sun Microsystems                   http://weblogs.java.net/blog/kohsuke/