Something about usability...

1. Configuration creating

Why can you see 'Configuration Steps' only after you've passed through some project setting steps sequentially?

I try to create project and set up some build configuration:

1. Administration -> Create project -> Create build configuration...
2. The next form 'General Settings' has no 'Configuration Steps' on the right of window. Let's click 'VSC settings'.
3. 'Version control settings' has nothing on the right also. Let's click 'Choose Build Runner'.
4. 'Build Runner'. There are no 'Configuration Steps'. Click 'Save'.

Very great. 'Configuration Steps' has appeared on the screen and stays there for the future using.

Why couldn't 'Configuration Steps' be presented when creating configuration begins? I think it'd be more convenient a bit and more obviously.

You make user to do some things in the mandatory order. But really I suppose many users click sequentally on the buttons in each screen as monkey... Whithout thinking... That's waste of time... Why does it need to click on the buttons in three form for getting view of settings only?

Actually I just haven't looked at these screens because I know that after all them I can get quite convenient navigation to set all option I'd like. Just like an ape it needs to click to 'next' buttons... Why?

7 comments
Comment actions Permalink

2. Installation

TeamCity 5 has been downloaded successfully. Now it's time to try to install it.

For example I have some application server (httpd, tomcat, jboss or something else) started and working at 80 port, but I've forgot this fact. What will we have then?.. After some actions sequence we see "JetBrains TeamCity SetupInstalled Services Run" dialog. Let's just click "Next" button. Everything's fine. It seems that TeamCity is already running and we can open web. But we will some confused after opening because there will be our application server started earlier. And nothing refers to TeamCity of course. When we have a look at TeamCity's Tomcat catalina log file we can see that 'Address already in use'.

It seems that we've installed TeamCity completely and successfully but really it doesn't work. I think some check for choosen (or predefined) ports to open will be very helpful during installation.

Also user needs to choose some account under whom services will be running I suppose. Let's try to choose 'Run under user account'. I'd like to start TeamCity under some other user instead of SYSTEM (it has been tried under MS Windows XP). No one works. We get different error messages (security restrictions, incorrect login mode, etc.) for power users and Administrator account. Nothing works except offered SYSTEM account. So... Maybe just there is no need to offer user to chose something if he can get mixed only.


3. Configurations sorting

Let's imagine that we already have the some project and the three build configuration there named 'vs the first', 'ant the second' and 'maven the third' (attached pic01.jpg). And I'd like that these configurations will be executed sequentially being chained. So let we go to "Build Triggering"/"Dependencies" and add build dependencies for 'ant the second' (that it runs after 'vs the firts' built) and for 'maven the third' (so that it runs after 'ant the second' built) (attached pic02.jpg). So we can get all configuration to be built when we start 'vs the firts'. Very great. But... The configurations appears in the 'Projects' tab in the alphabetical (?) order. And when we start some configuration to build we can't imagine what will be executed as the next one. It's very unuseful,  especially when we have many projects and e. g. ten configuration inside of each, depended each of other but unsorted correctly. Though now we have dependencies graph and correct sorting could be done.

Now we only can do some trick and rename configuration so that they be sorted in alphabetical order (attached pic03.jpg). But as you know it's not nice decision because we always can change configuration build sequence, add/remove configuration or do something other changes that can affect to build order.


4. Configuration editing

Why are there two views for editing configurations?

The first is "Projects"/"Some project" - "Some configuration" - "Edit settings" (from popup menu).
It's a quite convenient edit section.

The second we can get passing the next steps:  "Projects"/Some project" - "Some configuration" - click it/"Settings" tab.
Very many letters merged into continuous text. Just unreadable...

Why it needs to have two absolutely different possibilities to set up configuration options? In addition it's impossible to use the second one. When you can get this causually you really can be mazed. User gets used the some settings view and if he get the other view it really complicates his customary actions.


5. Maven settings

Why can't I specify the 'working directory' for Maven configuration in the "Runner settings"? I can do that for 'Ant', 'Command line', 'MS Build', 'sln2008', etc. I'd like to set the directory when the pom locates and nothing else.

Look also at the comment under the "Path to a POM file" text box. "Specified path should be relative to the build working directory. When empty <build working directory>/pom.xml is assumed." What is the "build workind directory" is if we can't define this one?

Ok, we can read the manual (though we are not interested in that actually), and get the next: "By default, Build Working Directory is the same directory as the Build Checkout Directory." So what if I don't use some of source version control systems? Checkout directory will be blank. And... where should my maven project be then? I didn't catch that... It's very strange to define vcs checkout path in the one section to give to know where the project should be for the other section if we don't need that.

Also it's strange that no possibilities to set the absolute path to project in the settings (why only 'relative'?). Especially for maven confugirations as the pom file lies in the root of project directories structure. I don't think that simple parsing of pathes to define what is root, what can be executed etc. is not very big complexity for you. The software should be a bit clever otherwise why it needs?

And for all project settings it will be more comfortable to have simple dialog to choose project file (or checkout directory) in the file system. So that there wouldn't be need to do copy/paste actions with pathes. It's just strange in the contemporary computing world.


PS I think the increase of functionality is the good thing of course... But the main goal of similar tools is convenience to do what user wants. At the high speed and without any thoughts like "how can I do that" or "why it doesn't work". For example someone need to create auto build of maven projects. Now it could be more fast write shell script to get sources from svn, run 'mvn clean install -Dmaven.test.skip=true' and hang it on cron for example than take apart what is the 'working directory' and why it can't be define where it  be expected...



Attachment(s):
pic03.jpg
pic02.jpg
pic01.jpg
0
Comment actions Permalink

Installation

1. Port issue
What port was busy in your case? In fact I tried to reproduce this issue but could not. Installer correctly detected the port is busy and have shown me the warning. What OS you are using?

2. User account
Again - works fine for me. Although I tried it under Windows XP.

Configuration sorting

While I agree there should be a way to configure order of build configurations, I do not think it should be somehow linked with order of builds triggering. There are several feature requests for build configurations sorting and hiding. And it seems this should be configurable per user. Simply because there are many roles in teams and different roles may require different set of visible configurations and different order of them.

Feel free to vote for this and related requests: http://youtrack.jetbrains.net/issue/TW-5948

Configuration editing

As for unreadable text - please submit a bug report with screenshot.
As for different ways to edit, well Settings tab did not meant to be used for editing - it is a summary of configuration settings for those who do not have access to editing UI (not all users have administrator privileges). Links "Edit" on this tab because it seems to be natural to place them there.

Maven settings

As for working direoctory: please vote for this request: http://youtrack.jetbrains.net/issue/TW-10666 , there were no such setting because it was not required.

Why we do not allow to choose a file from the filesystem? Well, from what filesystem? From the filesystem of the server? But the build will run on the agent - on another machine. This is also the reason why absolute paths should be avoided. It smells and does not feel correct if a build script or its settings are tied to an absolute path.

Although I agree that documenation is not clear enough if it uses term build working directory, in fact build checkout directory should be used. And in case of Maven runner - this is the same.

Thank you for your feedback! We know that UI is not perfect and there are many tasks that need to be supported better in the TeamCity UI. But everyone who did UI design knows this is probably the hardest task in software development. Some things may look strange but often this is because other options even worse. We do our best and believe me - we are spending much time designing and re-designing UI.

0
Comment actions Permalink

1. Opened ports. I have standalone Apache Tomcat at port 80. It was run as service for other needs. And it was runnig during TeamCity installation process. Operating system is MS Windows XP SP3.
There were no some error messages from installer, TeamCity services was started but your Tomcat couldn't bind the port 80.

2. Service accounts. Well, I don't know how you can reproduce this. but I try install TeamCity also at laptop (Windows Vista) and another one (Windows 7) and got the same issue.

3. Configuration sorting. I give you some example from real life. I have the one project that contains 12 build configurations. The most of them are Visual Studio C++ and C# projects. And all this stuff must be run in the strongly defined sequence because of dependencies of built C++ libraries and C# assemblies. So what can I see on the screen?.. I run the first configuration that is the start point of all these sub-projects. There are 12 items on the screen and it's not understandable what should be started in the next step after latest successful build. I see the real chaos... Imagine that picture for example – you see that 11th configuration is failed and you think that all above was successful... though really it (11th) was the only second in the all build chain...

4. Pathes. It's responsibilities of your system user what pathes he gives you it seems. Your explanation sounds reasonably, but it sounds like programmers abstraction. The user lives in the real life. He downloaded your installer, set up it... He has web settings system (your tomcat with jsp and hsqldb) and default build agent on the one machine under the one operating system and in the same file system by default. It's the typical case and you offer this one by yourself. And it's quite well. Anybody took some computer, set up your soft and has working build server. Your words has a weight but... if user wants and needs that, why can't he do it? Than less similar facilities you give to user to simplify his work than less wishes he has to use you product...

...and... you allow user to set the absolute pathes in checkout directory for example... so it conflicts with what you said... user needs more comfortable way to choose directory, files or something like... every system gives him to do that via 'select file/directory...' dialogs... instead of copy/paste that you offer... if there is the case if he doesn't need this, he will enter path by himself... it's really looks like from the past...

maybe 'file choose' dialogs is not the best way to do this but it's apparently better that to require from user to 1) open some file explorer, 2) select file/directory, 3) copy this file name (that can be required some more actions), 4) return to your web interface, 5) past copied name...

if you don't know where user intends to choose file/directory from so offer him to choose place where... your build agents and settings service can give information about file system where they are and what directories structure they contains...

0
Comment actions Permalink

I've just wanted to say that 'functionality' also as some sort of 'abstractions' in many cases is not really that user wants. It's important, yeah. But there are similar software products at the market that have I think more technical possibilities than TeamCity has.
And the most of them are very complicated, difficult to follow... You just to try to get up to them... TeamCity UI looks some like Bamboo even...

It'll be honest to say I don't like all these products. Also as I don't like TeamCity actually. All these have been created not for people. It's developed by programmers with programmers touch for peeople who think in the programmers way.

You add maven support, git support... something else... Yeah, it's cool...But try to get the following thoughts – if I'd have svn as version control system only and ant java projects support only and after TeamCity installation I would set all I want without any questions, without any thoughts about 'how can I do that' or 'what the heck is going on' and won't some need to investigate 'how it works', you really make me happiest user of continuous integration system and who will forget all another ones. And I suppose not only me...

You make changes... new features.. but the core is the same. The core that user looks at. You didn't change that. You said you very much time spend for UI development. But I used TeamCity 4.0 earlier and now I've been triyng to see at version 5 (just for my interest). Nothing changes in usability. There are only some silly bugs (see my other two posts) and the same strange things user has to do for typical tasks.

I see you certainly have to try to compete with other similar systems, have some development tasks for that... But it seems you could make this product much better than it is now... But unfortunately the way you follow now leads to all other similar systems that have very many various features, but hardly to use...

It so happend that I faced to using TeamCity for about 2 months, I have to admit it's not the worst product I used, and after that I decided to give your some feedback. Maybe I did mistake and if you just want to catch up Bamboo, Automated Build Studio or something like, you choose the right way. But maybe you just look at your product from the wrong side... Does it need to make one more product like the others which are already?..

0
Comment actions Permalink

Installation

Did you make fresh install or an upgrade? In case of upgrade installer does not check for ports to be busy, because it is supposed that you have server.xml file left with all ports configured in it and the ports are correct. Maybe this is not always true. Anyway, it would be great if you could report these issues as bugs to our tracker.

Configuration sorting

I can offer you a simple workaround. Just add letters (a. b. c. d.) before names of your configurations and they will be sorted in the order you need. This is just a workaround, until we implement the feature. If you need to sort configurations in dependencies order - please submit feature request, I beleive we don't have one (which can be the reason why it's not imlemented btw).

Paths

There are technical reasons why we can't always provide you wil file chooser, especially for files on the agent. First of all - on which agent, in our installation we have about 50... From the other point, when you configure build configuration settings, the agent itself may not have source code of the project (there were no builds of this project on the agent), so it is pointless to offer file chooser in this case. And finally, since automatically provided checkout directory depends on build configuration VCS settings absolute path to pom.xml will change once you change VCS root settings, the build will fail and it won't be easy to discover why.

If checkout directory is set manually (which is not recommended, because in this case TeamCity can't optimize disk storage usage) then paths likely to be the same, but how many users choose to use custom checkout directory given that it is not recommended practice?

Maybe a better approach is to offer VCS repository browser, but in this case selected path will be relative to checkout directory.

Other

First of all this is not the goal of TeamCity to keep pace with Bamboo or other tools (some of these tools need to keep pace with us, because they have less features). Our goal is to provide convenient tool for software developers because professional programmers (not common users) our main taget auditory. And life is such that tools for software development need many options and many features. This is the fact, otherwise you won't sell the product.

And you just confirmed this fact by asking for a working directory setting for Maven runner. It would be simpler for user not to have these settings at all, just path to pom.xml. But in real life this won't work. In real life you need some of the options, others need other options because every project is unique. Don't you think we added GIT support just because it is cool new version control system? Well, that's the reason btw, but the more important is the number of votes for this feature, and a lot of complains in the net we've heard.

The core UI did not change for a long time because of many reasons. One of them - it is convenient for many users, and if you want to offer something new you have to be very careful. In 5.0 we changed presentation of the My Changes page - we beleive that information on this page is organized better than it was in previous versions, it is more user oriented. We also tried hard to offer some significant UI changes in 5.0, but it turned out that these features need more polishing. I hope we'll be able to offer some of these features in subsequent releases.

Anyway feel free to submit your thoughts. We are interested in any feedback, be it mostly negative , or positive.

0
Comment actions Permalink

Installation

I have installed TeamCity5 dev. build earlier and it was stopped lately.
When I was installing TeamCity5 release the installer offered me to uninstall the old one (see attached image).
But when I confirmed uninstalling I supposed all files are deleted... including tomcat's server.xml...

Others

Thanks you very much, Pavel, for all your explanations. I catch that. I would like to tell also my response is not negative or positive.
You make product that can be used actually. I think it's worthful product. And by the way I personally don't need this one...
Just I said I used TeamCity some time because of circumstances and noticed some things that seems strange because they strike the eye...

PS It was tried to use various continuous integration systems and if it will be necessary to answer at question 'what the system should be choosen to use' I will not be able to answer. Unfortunately at this point this decision can be made only from such reasons as cost, system requirenments, various features etc. but not by usability and quality excellence.



Attachment(s):
img.jpg
0
Comment actions Permalink

As for installation, in fact uninstaller does not remove server.xml file intentionally - there can be user defined settings. Maybe installer should check ports in case of upgrade too.

And I agree with you that usability is important. The problem, that no one pays for usability alone. From the marketing point of view it is hard to promote products based on usability, while not offering some advanced features at the same time. So software vendors have to sit on both chairs.

0

Please sign in to leave a comment.