3

I like the clearer icons and more generous spacing of the "All Activity" landing page, but I find the alternate-line text staggering to be much harder to scan. The 1.0 "All activity" page showed one line per push, and all the columns (date, repo, user, commit message, etc.) lined up so it was easy to see what the activity was.

It looks like it's trying to cluster several pushes under a header, but none of my push entries were clumped together, so maybe that's not what's going on.

I just find this hard to read: alt text

EDIT: I understand now that the breadcrumbs represent the push activity, and the blue rows underneath represent the commits that were pushed. I always push each time I commit (unless I have some reason not to), which I guess is why I'm seeing them always paired.

As I've said in my comments, though, I personally don't find the push information very interesting, especially in the case where there's a 1:1 relationship. Some of the information (date, user) is duplicated, and I just find this layout more busy than the previous screen.

I would be interested in seeing the commit activities, clumped by repo or by user, for the last day or so.

FOLLOWUP QUESTION: Can anyone explain to me the value of the push activity information at all? I mean, what does it matter that Mike was the one who pushed, and it happened at 8:17 this morning? Isn't all the important information in the changesets?

Fog Creek Case FC1943895

flag
Hey Henry - Could you clarify "alternate line text staggering". I want to make sure I understand the issue. – Jason Rosoff Aug 30 2010 at 18:56
I think I understand what you mean. What you are seeing there is a series of single-commit pushes. That means you're getting an event header and one changeset for each entry. The new design is slightly busier in that case (because of the graphical treatment around the event headers), but we haven't change the overall structure of the events at all really (other than the order of event type and effected repository) – Jason Rosoff Aug 30 2010 at 19:02
@Jason -- Now that I'm in the beta I can't see what the old one looked like, but I remember it was cleaner. I hadn't realized the headers were supposed to clump several commits from the same push. Unless I'm doing something experimental or have no internet access, I generally push immediately after a commit, which I guess leads to this view. But I don't really see how it's useful to show both the push and commit... All I really care about are the changesets for each repository. – Henry Jackson Aug 30 2010 at 23:38
3 
I cannot disagree more strongly. The new design is much more useful as far as I can see. It's now much easier to scan for changes of interest. – Tom Cabanski Aug 31 2010 at 3:10
1 
I can't think of a way to reduce the clutter without losing information, but I do really like Anton's idea for same-repo pushes. I just added a mockup: kiln.stackexchange.com/questions/2017/… – adambox Aug 31 2010 at 16:09
show 1 more comment

1 Answer

3

As a slight UI improvement I want to propose to collapse bulky breadcrumbs (highlighted with red rectangles in the picture below) if activities have the same action (push/created/deleted/etc.) and the same target repository. And separate groups of changesets pushed together only by author and timestamp. Unfortunately, it won't help Henry in that case (as shown in Henry's picture), but it could be useful in this case:

Instead of this:

alt text

Only show the push info that's different (the author, date and time): alt text

But, honestly, I push several changesets more often, than a single changeset, and so noticeable breadcrumbs help to scan activities easier.

Answer to Henry's follow up question: Obviously, changeset information and push activity information have absolutely different missions. You can extract a lot of useful information from Kiln activities (including push activity). Just several use cases:

  1. You have strict rules in your company and you allow to your employees to make changes in Kiln only during business hours. Activities help to watch over the employees actions.
  2. If someone made a commit with wrong author information (wrong entry in local hgrc file), you will always know actual person who pushed changesets to Kiln. The same problem with commit date and time. If someone has wrong date/time settings on his local machine, you will always know at least actual date and time of push.
  3. Activities allow to see sequence of users actions. If you have only changeset information, obviously, you will able to see only sequence within each repository, but not within the entire Kiln account.

Answer to Henry's Re:followup comment below:

If you want to see when an employee was working, the datestamp on the changeset seems much more important than when it was uploaded;

First, as I said before, if an employee has wrong date/time settings on his local computer, the date/time of the changeset doesn't already seem so important. Moreover, in most cases it doesn't matter when a programmer made a commit, it only makes sense when he shared his work with other programmers (i.e. pushed changeset to Kiln), and when other people can use his contribution.
Second, lets see a bit deeper. Probably, if your company has strict rules about working with source code management system, it has some reasons. For example, every day, after business hours, an administrator makes a backup copy of Kiln database. So, you have to keep the database with source code for each day. That's why it could be useful to know if someone makes changes, when it's not allowed.

Identifying incorrect settings is a noble goal, but hardly seems worth all this effort.

What effort do you mean?! Kiln does all the things automatically.

Even now, the push activities are clumped by repo... by definition you push to a repo, not to the account. Showing just the changesets for each repo would still have all the information visible.

Activities provide information across all projects and repositories. If you work with only one particular repository, maybe other information isn't important for you, but if you need to get know about the work of other employees, it's extremely inconvenient to look into each repository.

link|flag
Yes, in your case this looks cleaner. I almost always push immediately after I commit (unless I have some reason not to). But as I said in the comment above, I don't really see how the push activity is useful. I'm much more interested in the COMMIT itself, rather than when the changetset happened to be uploaded. – Henry Jackson Aug 30 2010 at 23:41
Along the "collapse" line of thinking, being able to group changesets in different ways more like the FogBugz filter page does, may also allow people to see things how they want. For those that like the "push grouping", order them by pushes. Those that want to see things by author could do that, and those that only want to see changeset histories by repo could do that as well (with some fun nesting stuff too if you really wanted to go all-out with the UI) – cdeszaq Aug 31 2010 at 13:21
1 
I like the mockup (second image), because it allows me to more easily see who's been editing what, and downplays the Push details, which I consider of secondary importance. – Henry Jackson Aug 31 2010 at 18:49
@Anton, Re:followup -- You bring up a few good points, although those answer strike me as very minor details: 1) If you want to see when an employee was working, the datestamp on the changeset seems much more important than when it was uploaded; 2) Identifying incorrect settings is a noble goal, but hardly seems worth all this effort; 3) Even now, the push activities are clumped by repo... by definition you push to a repo, not to the account. Showing just the changesets for each repo would still have all the information visible. – Henry Jackson Sep 3 2010 at 15:12
Henry, unfortunately, here is a lack of space to answer your comment. Please, see updated answer above. – Anton Moiseev Sep 3 2010 at 20:58

Your Answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.