Közzétéve
2009-05-25 05:11
A few weeks ago, we started designing the new looks for contact edit screen, as a part of usability focus for CiviCRM 2.3. Quick remark on this - it's a very last minute to submit your feedback on that improvement, so if you have some good idea, come back to this blog post and submit your comments.
Anyway, now it's time to introduce some changes to contact viewing screen! Following the same process as previously with contact editing, we prepared the screen mockup for your perusal. Make sure to read the rest of this blog post, take a close look at the mockup and post your feedback/comments/critique/ideas below or on Usability forum board. Special humble request to all the CiviCRM integrators and consultants - if you have a chance to discuss over this mockup with end users that you work with, it would be most helpful if you could do so - and let us know about their reactions.
Here are quick highlights explaining different concepts behind the mockup. We're most interested in your reactions to below points, but don't limit yourself too much - all the remarks going beyond below set of concepts is most welcome as well.
- Information is more condensed now. The goal here was to save screen real estate and show more information at a glance, hopefully without significant loss to layout clarity. In most cases, you should be able to see all the information stored about the given contact without scrolling, unless there is really a lot of it. There are actually two versions of the mockup - the one linked above, and another one, with minimal amount of information - so you can see how does it look like in both cases.
- Custom data groups are presented in two columns. Again, the same motivation as previously, saving space on the screen. If you tried to imagine how would your custom data look like in such layout, would it be an improvement for you?
- Section headers for built-in fields are gone. The assumption is that data presented there is quite self explanatory and don't require additional heading. The obvious advantage is saving some space on the screen, the disadvantage is slightly less clarity about how data is grouped. What are your opinions?
- Collapsible sections are gone. It's still possible to turn given sections on and off in CiviCRM configuration, but you are not able to hide/show them by clicking little plus/minus sign, like on old layout. Step forward or not? How many of you were using this functionality?
- Tab names contain the number of "objects" stored about given contact. This should provide quick information about "what's there to look at", when you visit specific contact record.
- Screen has been optimised for 1024x768 screen resolution. It should look well in higher resolutions, in lower, there might be different quirks and problems.
- One last question/doubt - name of the contact is displayed twice: above tabs and below them, with all the remaining information. Is it good or not? Cause we couldn't decide. :-) Would you rather have the name of the contact displayed only above tabs (and not repeated inside contact summary) or have it placed inside of each tab? /tabs are not really working by the way - it's just a mockup ;-) /
- Data is grouped in similar way as on contact editing screen. This will potentially open the possibility of introducing inline editing of sections in future, should also make it easier for user to understand how data is segmented.
- For those HTML geeks out there: we'll be trying to use DIVs as much as possible to allow changing the looks of the screen using custom CSS stylesheets. Actual HTML in the mockup is the effect of many experiments, so don't get attached to the way how page source looks like - it will be cleaned up when actual screen is implemented.
- Ability to move specific sections around is not a part of the focus for current version and will be approached in next phase of usability improvements.
Comments
Nice work! Thanks!
Overall, I think this is an improvement and there a several gigantic features that will make my life easier. Especially being able to see the number of items in a tab which will keep me from having to wait around for empty tabs to load!
At first glance, this page seems busy and it's hard for my eye to go to the important stuff. Maybe this is part of what I shouldn't get attached to? Anyway, FWIW, here's what I think would help:
1. Get rid of the bold on labels (it's the info we are focusing on, not the labels)
2. certainly don't bold the skype ID. Only bold the primary phone, and primary home address, perhaps the primary e-mail.
2. I find the shading distracting
3. You've made the type size larger. Personally I think it would be easier to read with the existing type size. I can imagine those with older eyes might disagree with me.
4. Actually, what I'd suggest for type size is to make the more "minor" fields (ie, privacy and demographic sections) as a smaller size and retain the larger for primary fields.
I like the two column approach, including for custom data groups. I'm glad you got rid of section headers - they did not always seem to conform with how users organized info in their own heads.
I was using the collapsible sections - for custom data. I have a couple of custom data sets that pertain only to selected groups - ie, legislative details (committee assignments, districts, etc) that only pertain to a fraction of my list. I'd miss it.
Hi,
First, way nicer. Well done.
I'd suggest:
1) Yes, labels should be different than the text, but here it takes the focus on them. They aren't the main item. I'd prefer the greying option.
.label {color:grey;} makes it nice
2) Don't like duplication in general. What about moving the buttons (edit...) above the tab and get rid of the second name ?
3) Spaaace. Let the screen breathe. You're trying to pack too many stuff within. Leave more space between the blocs.
took out the margin:0 and went to the default. Works better.
4) What about using more icons ? That's about time to put "pen" icon for edit and "trash" icon for delete. These are fairly standards, take less space, and break the monotony of texts.
Might be used as well instead of some labels. eg "enveloppe" icon for mail, "phone" icone for phone...
Should be actually set in the css. Easy to switch... if you put the right class in the label...
5) Really, Really, you should use class to put the individual,hh, org and the al icons. It isn't an![]()
, it is a class="individual" with .individual {background:url(...). Putting an icon as an image like that is a failure of proper separation between the presentation and the content.
6) 'Go to' is an action that is hardly never used (the dashboard/user record). However, takes most of the space. I'd suggest to go icony, or menu/select (like activities)
7) The tabs are super cute. nice, really.
8) a div inside of a table inside of a table... I'd suggest to simplify the structure. Go for table if you want, but don't put two dozen ;)
Take care, IRC/IM me if you want me to detail.
X+
Thanks for feedback - a few comments:
Ad 1. Applied. :-)
Ad 2. Buttons are tab specific, so we need to keep them contained within. When you switch to another tab, the set of actions will change.
Ad 3. True, the screen is packed. :-) However, I'm thinking about introducing more space by increasing fields padding, not by releasing margins. What do you think?
Ad 4. If we introduce icons for actions, this needs to be introduced system-wide, so it's a decision coming out of contact view screen and I would rather postpone it for now. I'm planning to introduce informative icons for Bulk email and perhaps for primary objects (email, address, etc). I would rather avoid introducing icons as labels.
Ad 5. It's a mockup. ;-) Made note of it, will introduce it when implementation starts.
Ad 6. Good idea, I will definitely think about something here.
Ad 8. It's a mockup, again. ;-) However, the idea is to have one surrounding div (like #crm-container), than each table with specific data group (phones + IMs, emails + website, addresses, etc) in separate div, so you can lay out the screen in one or two columns with CSS stylesheet.
How difficult to properly put in/back the subtypes ?
Ie if it only applies to the "subcontractors", or "major donors" or "members", the section should be available only for them, not to all the individuals.
Works well for the type of events, we should have type of contacts in the same vain.
Might make sense to mix these subtypes with HH, ind, org, that are subtypes of contacts anyway, only limited to 3 and hardcoded.
X+
I like it.
Tab counts are great (hopefully those extra queries won't impact too much).
I think the go to dashboard & user page should remain links, not buttons, since they are destinations, not actions.
It does look a bit cluttered, but most contacts won't have this much information.
I think the group headers need a bit more emphasis to indicate to the eye "new group starts here", maybe a larger font, or thicker border-top.
I disagree with the first poster on one point. I think labels should be bolded. When you arrive at the page and you want to know some specific information, lets say the contact's marriage date, you can scan quickly to find it. If values are bold and labels not, then you see several dates and it takes more effort to find the one that you want. But this is just theory, it will probably take side-by-side examples of each to know for sure.
I think I agree about the zebra striping. While zebra striping is proven to be a good thing with tables, these are not tables. The striping adds confusion in that it does not match all the way from the left column to the right column as we've come to expect. Though again, I think I'd need examples of each to know for sure.
Thanks for feedback! :-)
Regarding "go to dashboard" and "user page" links vs. buttons - the idea behind making them buttons was to see how unification of "actions bar" would look like. We might end up with coming back to making them links.
Regarding "side by side" comparisons: do you have Firebug installed? It's super helpful for checking such "options" with single click - you just disable/enable specific property in CSS stylesheet. If possible, please play with it and share your impressions.
As for zebra stripping - I was trying to keep it very light, just to help in distinguishing respective lines with data, but I agree that it might introduce some light confusion regarding the relation between left and right column. Let's wait for more reactions.
Good to see the progress.
The new Tabs are great.
I would tend to agree with a bit more space.
I think section heading need to be bold to help guide the eye but a grey could do it.
I am not convinced about usefulness of zebra stripes ( too many adds clutter - I know that with spreadsheets etc, doing them in groups of 3 works really well, as the eye can easily follow across and remembers whether it is top,middle or lower of any group - not sure it will apply here though. But maybe look at shading by section eg so Phone/Mobile/Skype section is shaded, the Address section is not shaded, then Privacy/Method/Email Format is, etc
I thought the Dashboard/Record as buttons was more useful thank links as it highlighted them better and reminds you that you are stepping slightly outside the core civicrm area.
Shouldn't the text in the 'First Field' (the long one) still commence on the line after the colon, and then remain indented?
And did I say the new Tabs are great!
The problem with shading sections is that we never know how many rows given section will be made of - on above example, it's 3, but it might be 5 as well as 7. I'm guessing that in most cases it won't be more than 2 or 3 in one row. However, I see that row shading is quite controversial in comments, so will probably try to look at some different solution on next approach to this mockup.
As for "First field" in custom fields group, it's an expected behaviour for textarea/note type of fields. Having the label is separate line leaves more space for the value of this field.
I like this. Here are my thoughts.
I like...
I love the way this this shrinks down to a very narrow layout.
I also love the two column layout.
I think that styistically it is definitley going in the right direction.
I like the way that everything (or at least almost everything) is left aligned.
Ideas for making it clearer...
It is still to busy with two many different visual clues things- there are too many different layout elements. I've talked a little about this in the page I started on Interface design guidelines in the section 'Design elements'.
In this example, to distinguish label from value, you could either change font size, weight, or colour, and that would be enough, but changing all three isn't necessary. It also means that these changes are less available to convey other bits of information, like the difference between section headers and actual data, etc. i.e. if you've used bold to distinguish a field header then you can't use it again for links / clickable parts of the interface.
In this example, to distinguish between different fields in a section, this example uses differences in color and also horizontal lines. This means you have to use an even thicker horizontal line to distinguish between the wider sections. If you didn't use the first horizontal line, you could keep the second one less obtrustive.
What distinguishes Position, Employer, Nickname, Source and tags from each other and from any other fields? I don't see the rational for formatting these differently and would suggest they are formatted in the same way as other fields. This makes it much easier for people to remove the parts they don't need from the template, thus saving even more space.
Once you have started the two column layout, there are a couple of lines that go all the way across the page that (falsely) give you the impression that the content on the left is related to the content on the right. i.e. work phone is related to email, skype is related to website, privacy is related to gender. These should be removed.
In general, there are too many horizontal lines and some of them are unecessary, for example, the one between the actions and the start of the data. You don't need to signify this change because it is obvious. In contrast, you do need to show the border between two different types of custom data.
I think that a custom data group should always span the entire contact width and be able to have two columns inside it, rather than being half the width of the page. This will help people navigate custom data and see where headings are.
Hope this is helpful :)