Have a looksee at the commit listing UIs

Tagging and putting in the proper queue

Sam feel free to jump in and correct me here:

Design objectives

1. A universal, instantly recognisable visual language for commits.
2. Revisit content hierarchy
   1. Default hierarchy
   2. Shifted priority based on filter or view
3. Branch signposts and navigation

Here's the list of information given for each commit.

• Project
• Date
• Commit name
• Project branch
• User
• Message

Had a chance to go over the commit information with Marco.

Here's a first draft of a new structure and emphasis based on drupal.org/commitlog. View it here.

This helps me see the important information more quickly.

How will the right-hand links work? I'm guessing they'll take me to the commit log of the specific branch listed when they're fully implemented. When there are two labels, does that mean that the commit was also tagged?

So glad to have you looking at this :)

Nice! Some feedback.

Here's the visual order of importance, at least how I use the commit log. Others might have differing feedback.

1) What project is this? That contextualizes everything that follows, and I can easily say "meh, i don't care" and quickly skip to the next one.
2) The commit message. What was actually committed? This is the second most important thing, and everything else is way less important.
2.5) The diffstat, which got removed sometime in the past several months. That can also give an indication of how closely to pay attention to a given commit as a big diff stat = "Woah, lots of stuff" and a little one = "Meh."
3) Who did the committing? This helps me understand if I need to inspect it carefully or if it's a "Oh, merlinofchaos has got this, no need."
4) Where did they do it? (What branch[es]?) Helps me debug if something shows up one place but not another.
5) When was it committed? (Note that this is usually not that relevant; I'm usually only interested in the top 1-2 commits when I look on this page because I'm trying to troubleshoot something, or else I'm trying to get an idea of module activity, but that was already on the maintainers block on the project page before this)
6) Other info: e.g. the commit hash which I never use except as a link to gitweb where I can see the details.

Here's how the current layout scans:

As you can see, my eyeball currently has to skip all over the place to find the information. So +1 to finding a more streamlined way of presenting it.

Now let's contrast that with your mocks:

I love that the project name (most important thing) stands on its own and the date has a lot less promimence (also the "X time ago" makes a lot more sense than a specific date that needs math done on it). I dislike having to bounce my eyeball inward in order to get the second most important piece of information, so I would get rid of the indentation there (the <code> tags also helped visually set it apart before to make for easy scanning and losing those feels weird, but it might just be one of those things that takes some getting used to). I do not understand why the branch the commit was made on is so visually separated away from the rest of the information, when it's pretty important. If anything, I'd move the commit hash to the far right like github does in that mock, since that's the least valuable piece of information since it means absolutely nothing on its own. It'd also be nice to see a diffstat here, though I notice Github doesn't seem to show those anymore. Hm.

Great feedback! Here's V2

I'll tackle a few more issues in the next iteration. Let's keep things fast and light shall we?

Changes:

1. Switched branches and commits round. Reworded the sentence slightly.
2. Reduced the margin for the blockquote style. Your point about scanability is spot on. I was trying to humanize the commit message and make it look less like machine output. I'd like to see if we can solve both of these.
3. I reduced the width of the page to emulate a sidebar presence. I don't really like the commit message being acres away. Maybe coming up with some useful filters to place in the sidebar would be nice.

As a site builder, I care most about the project name and the commit message, too. After that, I care about the branch on which a commit has been made (Am I using that branch?) and when it happened (Was it included in the tarball I installed?). I don't care as much about who made the commit or how much or little code changed since my focus in on what functionality or fix is available (not that I would mind a diffstat, of course).

I really appreciated the formatting of the branches in the first version, although on a large monitor they were awfully far from the rest of the text. (fwiw, the ability to filter by branch is something I would use.)

I preferred the syntax of the first version, too. "Someone authored commit 6423AE an hour ago" was easy for me to scan and because of where the commit hash appears syntactically, even without knowing what it means, I can infer from the context that clicking it will give me more detailed information, whereas on the far right I don't get that. Over there, it's just an unlabeled string of characters floating around.

In any case, let's please remove the links to the commit view on drupal.org itself. Why would I want to view the same commit on an own page? Each time I want to see the actual commit, I've to double-check the commit link URL to make sure I end up on drupalcore.org.

missing tag

Untagging. This can be done post-upgrade.

fixing broken image

Ok, it's post upgrade. Can we get to @webchick's points in #7?

Also, why is this listed as "Needs review"?

It looks to me like the issue was set to needs review because the mockup back in comment #8 needed review ... it sat for a week with no comments before the status was changed.

I'll cook up another iteration on this. I understand git a lot better since I last worked on this.

Ok here's an updated version look at the rest of the comments in #7 and bearing in mind #10

http://lewisnyman.co.uk/drupalorg-commit-messages/global/index.html

• The commit id is aligned with the title
• I've added a border to separate each item, similar to comments in issue queues
• I've added the code styling back in but removed the bottom border, which felt like unnecessary noise
• Notice how the important information under the title happen to be links, which also highlights them against the less important information

That's definitely an improvement.

I have to admit that I initially was wondering where the commit id went. Afterwards it made sense. Looking at github though they definitely have more emphasis around it:
https://github.com/lewisnyman/drupalorg-commit-messages/commits/master

They really do seem to be the UI to follow as far as commits go. How would you feel about making the link to the commit id look more like a button? Maybe it's not needed.

Tagging +D.o UX

Why do we not use the full width?

@Bojhan What would we use it for? No one wants to read a commit message with a line length that long and it places the commit link even further away from the rest of the content.

The grey for the "less important" text will need to be darker to meet WCAG 2.0 AA.

@lewis could you give the contrsat issue a look? I am fine with commiting this change.

This is a good tool to check and see if you can nudge things darker/lighter.
http://webaim.org/resources/contrastchecker/

Ok how about this? http://lewisnyman.co.uk/drupalorg-commit-messages/global/index.html

Looks like we're ready to implement? Any pointers on how to set up a local d.o environment?

The blue #0678BE links should be darker on that grey background. Maybe #05639d

I don't know how to set it up locally. I assume you have access to devdrupal.org

Ah thanks got it - http://lewisnyman.co.uk/drupalorg-commit-messages/global/index.html

I'll need a dev environment set up I guess

Are these only CSS changes, or markup too?

For CSS, you can jump into any dev site which doesn't seem to have anyone else actively theming. You can also request a separate one, which I recommend if there are markup changes. https://drupal.org/node/1018084

Lewis - I think your access should still be good, unless your keys have changed.

Lewis, you're welcome to use http://eliza411-drupal.redesign.devdrupal.org/
Assign the issue below to yourself when you start, un-assign when done.

https://drupal.org/node/2169889

I'm happy to implement the prototype for reals if it's still relevant. Let's finish this!

It would be useful to know where this fits on the priority list for d.o improvements.

Thanks @LewisNyman for your work on this and offer to help finish off the prototype. It would be so nice to get this implemented.

some contribution credit issues have d.o profile improvements tag, and some have nothing and are easy to get lost (and not about profiles), so tagging to organize credit ones.