Skip to end of metadata
Comment: Migrated to Confluence 4.0
Go to start of metadata

Confluence 2.8 has undergone quite a few changes and improvements. Have a look at the general explanation of the menu structure and at the summary page for the UI changes in Confluence 2.8 to learn about all the details.

The staff at Atlassian are very happy with those changes - so what is your feedback? Did we miss something obvious? Are you entirely happy? Or are you somewhere in between - "Yeah it is really nice, but I wish there were a way to ...." ?

Any feedback is welcome!

(info) You can also take a look at the Confluence 2.8 Beta Release Notes, to get a preview of the highlights of this release. Try out some of the new features in our Test space.

Cheers,
Per

47 Comments

Hide/Show Comments

  1. Mar 25, 2008

    Bob Swift

    Yes, I believe it is a major improvement and will make some of the extensions fit in more naturally. There are a few things that you could consider as you think of UI.

    1. By moving some things to the far right, it makes things more difficult at higher resolutions. For example, the edit click is now a long way away from the focus of attention at the left. Similarly, moving the comment date to the right virtually eliminates it from view.
    2. In general, there are too many instances where the buttons for actions are on the far right or in other inconvenient locations
      • Edit screen - far right top and away from the comment and minor change fields at the bottom. Filling in the comment field should be encouraged, but it is often forgotten because of this placement
      • Link properties - buttons are on the bottom left, but are out of view until you page up. The input fields are top left.
    3. It would be nice if the edit help tips could be toggled off to give more edit space
    4. I think the drop-down list for the user name is functional, but not as welcoming as previous. Why is space drop-down first? I would think user should be first (like before).

    1. Mar 26, 2008

      Shannon Krebs

      Even at a normal resolution it is difficult to see the time a comment was made

      Also agree about the name menu, I think it should come before the space menu (for logged in users)

      1. Mar 26, 2008

        Adnan Chowdhury

        One of the reasons we have the Personal Menu closest to the right is because it is always there and we wanted to keep its position constant when there was no Space Menu (e.g. Dashboard, Search). Also we wanted the Space Menu to be closer to the Breadcrumb as both are navigational components for a space.

  2. Mar 26, 2008

    Tibor Hegyi

    Just a few more in addition to Bob's points.

    1. If I don't have permission to add content of any type, I still can see the "+Add" menu. If I hover the mouse over it, a gray line (border of the empty menu list) is displayed.
    Please remove "+Add" if the user lacks permission to add content.

    2. Space and User menus (top right) may not be intentionally aligned because they hide the labels for "Space" and user name, instead they should be displayed below them just as you did with the other menus.

    Tibor

    1. Mar 26, 2008

      Tibor Hegyi

      Just saw that the dropdown Space and User menus were aligned correctly in m7.

      1. Mar 26, 2008

        Per Fragemann

        Yeah, I have no clue why this is suddenly wrong. It works on out internal system with the exact same version (m9-r3). We will investigate (smile)

  3. Mar 26, 2008

    David Peterson [CustomWare]

    The last two emails I got notifying me about updates to this page (an edit and a comment) were both in German. Is that intentional?

    1. Mar 26, 2008

      Per Fragemann

      No, it is a bug. I occurs because I have changed my locale to German, to test our improved translations....

      1. Mar 26, 2008

        David Peterson [CustomWare]

        I figured it was something like that. Just keeping you posted (smile)

  4. Mar 26, 2008

    Shannon Krebs

    I generally like the new menus, but I think the latest version of them in milestone 9 are too big, looks "fisher-pricey" to me (smile)

    Also I miss being able to tell if I am watching/favourite a page just by looking at it without having to look in the menu.

    1. Mar 26, 2008

      David Peterson [CustomWare]

      Yeah, I concur on both points.

    2. Mar 26, 2008

      Bob Swift

      Agree as well. Would it be possible to show an watch icon or favorite icon only if they are selected and still use the tool menu for setting/unsetting. Also, suggest just using a more standard check mark to distinguish between the on and off settings, at least the watch icon is hard to distinguish and for new users, either are obvious.

  5. Mar 26, 2008

    Bob Swift

    Just noticed that labels are now at the bottom of the page content. I think they may be lost there with pages longer than one screen. You would have to find the end of content and beginning of the comments section - not easy to do with longer pages with lots of comments.

    1. Apr 07, 2008

      Nicholas K

      I would definitely have to agree that having the labels after the main body of the content is not helpful. This label placement does not encourage users to add labels to the page. As a wiki I see one of the functions is to gather the collective intelligence or wisdom of the crowd to improve the overall content. By placing labels after the main body of the content you make it more challenging for this to take place.

      Additionally, let's say a user was trying to "clean up" the labeling on a set of pages, if the labels were placed after the creation/edit information then a user could quickly browse between pages and add/edit labels. In this beta release a user would have to navigate to each page and then scroll down and "find" where the labels are on the page. This would be very time consuming and decreases the overall usability of the wiki for labeling.

      I see labels as a key navigational element, especially with your upcoming ability to "drill down" into labels. The proposed placement of the labels takes away from the simplicity of using labels for navigating/filtering.

      Thanks for  the great work.

  6. Mar 26, 2008

    Bob Swift

    Suggestion regarding comments. How about something like:

    <pic> Per Fragemann commented about 7 hours ago <perm link>
    ...

    When this gets compressed, just leave the first line, but use a smaller font and keep the perm link. Also, make sure there is more of the text - now it seems to be cut off after only half of the page width.

  7. Mar 26, 2008

    Sarah Maddox [Atlassian Technical Writer]

    Quoting a comment from 'Anonymous', which was originally placed as a comment on the page titled Using the Confluence Screens:

    Congratulations on the improvements. I've just noted, however that if you increase/decrease font size (ctrl+, ctrl-) in Firefox/Mozilla (WinXP - not tested others) that the top-left breadcrumbs start breaking strangely and do not revert back to their original location when undone. A page reload fixes things, but it is annoying. IE font resize attempts still fail because of the continues use of non-relative css (sad)

    1. Mar 26, 2008

      David Dembo

      It's definitely a much neater interface, but there are some fairly significant issues as mentioned above, particularly to do with the visibility of important UI elements/information. Some of the issues I have with it (mostly mentioned above) include:

      • Positioning of the labels - especially on a page with comments, they can be difficult to find. To be honest - the labels being at the top of the page was one of the biggest things that I preferred about Confluence's UI as opposed to MediaWiki's. Labelling is an extremely important mechanism for keeping a wiki organised, so they should be clearly distinguishable from content rather than buried in it.
      • Attachments - there is no visible indication that a page has attachments - you have to hover over the 'Tools' menu.
        • Besides the fact that a menu of any kind is not ideal for attachments, a 'Tools' menu is not particularly intuitive.
      • 'Tools' is also unintuitive for the page Info link.
      • I agree with the point about favourites/watch too... out of sight, out of mind - people will be less likely to watch pages which could in turn affect contribution.
      • I don't like the new style of expanding for long breadcrumbs - if there are 7 or 8 collapsed nodes, the expanded breadcrumbs take up a LOT of screen real-estate.

      On a side-note - there have been a lot of significant UI changes over the last few major versions. The way they have been implemented, users have no choice but to adopt them all if they are using the default theme but still want to retain the ability to tweak the theme via the admin screens. It'd be nice if future UI changes were perhaps done in such a way that administrators could more selectively adopt specific changes... it'd give them the flexibility to:

      • Adopt the changes that they like, while not having to sacrifice the UI elements that they preferred from older versions - e.g. they might want to use the new comments style while keeping the tab style for page links.
      • Roll out changes gradually, allowing the end-user to adapt rather than making several major changes all at once every few months.

      For example maybe there could be an options page with settings such as:

      • Labels position: Top/Bottom (e.g. instead of just changing the position in 2.8, an option to change the position could've been added)
      • Comments style: Classic/Compact/etc
      • Breadcrumb Expansion: Horizontal/Vertical
      • Browse Space: Link/Menu/etc
      • Page Actions: Tabs/Menu/etc

      A big advantage of this approach is also that it could provide a means for developers to extend the UI to a greater extent/more easily. For example the Approvals Workflow Plugin could add a setting to control if/where the approvals are shown, rather than requiring users to edit the page layouts. Or somebody could design a funky new way of organising the page actions and package it as a plugin that adds an option to that settings screen, and make it available through the plug-in repository.

      Just some food for thought. (smile)

      Edit: 2.8, not 2.9... getting a bit ahead of myself. Also, this should've been a flat comment not a reply to Sarah's. Coffee time...

      1. Mar 27, 2008

        David Peterson [CustomWare]

        Yeah, I agree. I have long wished that

        a) Various UI elements were able to be turned on or off by theme configuration options. (eg, the 'children' list, comments output), and
        b) There were better ways to inject small chunks of custom code into various locations in the theme.

        It would make life so much easier for creating more complex plugins.

      2. Apr 07, 2008

        Frank Stiller

        I agree too.

        We are currently using 2.5.6 and because of the ui changes (and some plugins) we were not completely able to update to a 2.7. Now have i copied my styles to the 2.8-rc1 and could not even login as the link is just not shown. Also i am currently asking myself where has the site-css.vm file gone.

        Like David suggests, a more flexible configuration would maybe make sense here. Is there a Guideline or a change note on what you exactly change in the single layout.vm's? That could help to get back the company layout a bit more quickly.

        If its not mentioned already: the tooltip of the Remove-Comment-Action says: Permanent link to this Comment
        Edit: ok Edit, Remove and Reply have the same tooltip.. and why am i able to Remove other peoples comments? (at least i get the "are you sure" message (smile))

        1. May 06, 2008

          David Dembo

          At the risk of sounding like I'm beating a dead horse, we've got the same situation at the moment. I'm getting pressure from our Technical guys who want to upgrade to implement all of the post-2.5.6 security fixes. I may be able to work around some of the UI issues introduced by upgrading to 2.7 and retain the same (or at least a sufficiently similar) look and feel for our site, however 2.8 is completely out of the question.

          Basically we're going to be stuck with 2.7 until we've got enough free time to start playing around with Theme Builder and do a complete re-design of our site, which could be several months due to other priorities commanding our time. During this time we could easily slip behind another few major versions, missing out on plenty of security patches and feature implementations in the process.

          I really hope something is done to prevent this from being an issue in future, otherwise Atlassian are basically forcing people to decide between purchasing Theme Builder, getting a developer to build/maintain a custom theme plug-in (which could easily be more expensive), or dealing with the default UI and not being able to make any significant changes.

          I certainly would not be suggesting the use of the layout customisation screens for any significant changes - knowing what I know now, I certainly would not have made any changes beyond the magnitude of minor wording adjustments and such.

          I'd actually suggest that a clear warning be added to the layout customisation screens advising the above, and also suggest reviewing the appropriateness of having documentation explaining the use of these screens to 'modify the look and feel of Confluence'.

          Heck, I think this actually begs the question of whether it should actually be possible to modify the look & feel in this manner if it is only possible to do so for the default theme.

          If this is not the appropriate place for me to be voicing these concerns, please let me know who I should be taking this up with and how I can get in touch with them.

  8. Mar 27, 2008

    Tomi Strugar

    Ideas for additional UI elements and changes to some of the ones already proposed:

    I generally like the direction the new UI is going and agree with most of the comments made above. I'm no programmer but here are some "ideas" which might be of use:

    1. Display a row of content icons at the top of the page that are only visible when there is info associated with them. eg. Attachments - a Paperclip icon with the number of attachments in brackets; Comments - a Comment bubble icon with the number of comments in brackets; Labels - a Label icon with the number of labels in brackets.

    2. In an extension to 1. above, have a drop down arrow after the number of items that when you hover over or click, it lists the items. This way one can immediately see and then select an attachment say. For comments it would list the comments in brief format and if a comment were clicked you would go straight to that comment. At the end each of the listed comments the number of nested replies to that comment would be in brackets. The top link for the drop down arrow could be ALL to take you to the attachments page or down to where the comments start. The drop down will also be there for Labels to list those labels assigned to the page, and if you click on one of them it works as normal (taking you to a list of items with that label).

    2. The Edit link should be changed to a menu. Under this would be found - Page, Labels, Restrictions, Copy, Move, Remove and History (as they're all related to editing)

    3. For the display of the top level menu titles, a user preference to display, Icon+Text, Text Only or Icon Only would be ideal. A tool tip would be required for Icons Only.

    4. Return the toggable icons for Watch and Favourite but, so that it stands out, make the Favourite icon ALL yellow when a page has been chosen as a favourite. Perhaps put these in line with the icons mention in pt 1.

    5. An icon for the page's Tiny Link (to be renamed Permalink) could be at the end of the page title. Ideally, hovering over it would show the path with a tool tip saying Click to Copy Link.

    6. Moving the Print function to the browser's Print Preview makes sense for general use. However to me the Print, Export to PDF and Export to Word should all use a new function of "Output to...". This function, to be grouped under Tools, would allow one to choose from a list templates, defined elsewhere, that would reformat the layout (put in logos, headers, footers, etc) and then provide options to either print or export to PDF or Word.

    Personally I really like the Clickr theme so a UI that puts the content first and gets the wiki mechanics out of the way but still accessible is ideal in my opinion. Of course all these UI enhancements should take into account Accessibility issues. I think the new Move system is very good. I also have

    Keep up the great work. (Edit: fixed some typos and added pt 6.)

  9. Mar 29, 2008

    Tomi Strugar

    To the Space menu add Watch Space and Add to Favourites.

  10. Mar 30, 2008

    Miles Metcalfe

    Concur with many of the comments made above. New UI is overall nice and clean, however:

    • Action menus look "fisher-pricey". I'm not sure whether my reaction is because the graphics are a bit simplistic, or because I have a deep-seated aversion to menu-like elements on web pages;
    • I like labels at the top. It's a visual filtering tool - not labelled with anything I like, ignore the rest of the page (smile) Scrolling or labels is not easy.
    • Favourite and watch icons should be visible at the top of the page - like labels, I don't want to go digging for these.
    • Comment dates are pretty much invisible. What about: "On 31 March, Miles Metcalfe said:" and "date - commenter" in collapsed form?
    • Dave Dembo's comments above about the Tools menu are very perceptive. "Tools" is like the "Cog" button on many Mac OS X applications - it hides a multitude of sins rather than being a named concept. Perhaps the Mac OS X route is a little better - a (plus) to add the default object, and everything else bundled away on a (cog).
    • If you add watch space and favourite space to the space menu as Tomi suggests, some visual indication of favouriting/watching as with pages would be desirable. Perhaps a change of emphasis or colour?

  11. Apr 02, 2008

    Arno Bosse

    I think I see the logic of locations/content related to a space being under the "space" menu, and actions related to a page being under the "tools" menu. This helps explain as well why Attachments are listed in both areas (as content and as a potential action). So, in general, I think all this makes good sense.

    I concur with the others in this thread who would prefer to see labels listed at the top. A label is an important content marker, and should be visible right next to the title, not at the bottom of the page.

    Other comments from above with which I agree: not being able to see at a glance whether/how many attachments a page has is a real loss. Also agree strongly that when fairly big UI changes are made it is very helpful to allow parts to be switched on/off or to continue on with the old UI. Show/Hide children is a good example of something that can be toggled in this way. I also agree that having an icon for the TinyURL available right on the page is very helpful - it's 95% why I go to to Info on a given page.

    On a separate note, I'd like to put in a request for a toggle to show/hide profile pictures/icons in the dashboard. Right now we're commenting out this functionality.

    Overall, while I think the new UI is a big improvement I do hope 2.8 will not be released until the most requested change requests listed in the comments (and I'm assuming echoed by others via other channels) are taken into account.

  12. Apr 04, 2008

    Bob Swift

    There is another limitation with the way the tools menu. Before 2.8, I could be viewing or editing a page and go up to the attachment or info link and right click and select to view it in another tab. This was very convenient especially needing to look at attachments to complete an edit. With 2.8 menu, this cannot be done. So, if an attachment count or something is put back on the page, make sure it is a link as well.

    1. Apr 05, 2008

      Sarah Maddox [Atlassian Technical Writer]

      Hallo Bob

      I just happened to see your comment whizz by on my feed. The team are compiling a response to all the input on this page (thank you everyone for all the great suggestions and interest (smile) ) but in the meantime I'll give part of the answer to this last comment.

      The disappearance of right-click and open in new tab is indeed irksome. But all is not lost:

      • Right-click does work in IE7 — just not in Firefox (smile)
      • In Firefox, you can try control-click instead. It works for me. Now I just have to train my brain to use it.

      This a known issue. I'll leave it to the official product-management response to give more information.

      Have a great weekend!
      Sarah

      1. Apr 05, 2008

        Bob Swift

        Sarah, yes, CTRL-click works! Thanks for the hint (smile).

  13. Apr 06, 2008

    Colin Goudie

    • I agree about the new 'toy' looking icons. They are too big and also sit nearly 1cm off the top bar on my 1280x1024 display. This means nearly a whole cm of screen real estate at the top is wasted.
    • Labels should definitely be at the top
    • I second the idea of a row of icons showing important information about the page. Attachments, permalink, favourites etc.. Much better than having to dig into a menu

  14. Apr 07, 2008

    Brandi George

    I'm not sure if this is expected behavior or if it has already been documented, but I noticed on another page (see "Big +1" in Neil's comment on March 19th) that the "+" symbol disappeared from the text upon collapse of the comment.

    1. Apr 15, 2008

      Matt Ryall (Atlassian)

      Thanks for mentioning this, Brandi. We have an open issue in JIRA to track the problem.

      The same issue occurs with all excerpts in Confluence. You may notice it in the search results and dashboard excerpts as well.

  15. Apr 08, 2008

    Andrew Miller

    I fully concur on labels being at the top.

    In addition, a quick way to view the # of attachments on a page (not buried in a menu) is invaluable for us.

  16. Apr 08, 2008

    Tomi Strugar

    Confusion/bug in toggling comments: When you hover over a commentator's name the tool tip says "Click to toggle the display of this comment". If you click it the comment is toggled but you then get redirected to the commentator's profile (occurs in both FF2 and IE7). Note: Hovering over the commentator's picture correctly displays ~username (this is what should happen if you hover over the commentator's name).

    Minor bug: Also just noticed that in IE7 (not FF2) when a comment is toggled off and then on the Permalink icon changes colour. This happens for all comments if you use the Collapse All/Expand All or for just an individual comment if it is toggled.

  17. Apr 08, 2008

    Tomi Strugar

    Minor bug: When using FF2's Find function to find the terms 'edit', 'add' or 'tools; and then choosing Highlight All, the icons for the drop-down menus appear in the centre of the highlighted menu text (this only happens when the Highlight All function is used). And for the Edit menu (only), the icon and the highlight remain even after the Highlight All is turned off.

  18. Apr 15, 2008

    Tibor Hegyi

    How are Atlassian going to handle the above points, recommendations, ideas?
    Has any of them been built into 2.8 final?
    Has anything changed between 2.8 m7/9 and 2.8 final?
    2.8 is out - with labels at the bottom...

    Thanks,
    Tibor

    1. Apr 15, 2008

      Boots Wang [atlassian]

      Regarding placement of labels (on either top or bottom of the page), there's been quite a bit of dialog surround the UI and particular labels. People definitely have their preferences.  I am personally a *big* fan of the current layout, with labels at the bottom of the page. It's so much cleaner.

      Labels are great to help cross reference pages and narrow down your search. Having it immediately visible as you visit a page is not its main function, and adds clutter. The new layout is direct, and the focus is on the core content.

      just my 2¢s.

      1. Apr 15, 2008

        Alex Holtz

        Although I'm not entirely fond of (used to?) some of the UI changes (including the labels migrating to the bottom) I will say that it seems like Atlassian is attempting to pull the page title closer to the context of the page, and allow the title to become part of the content - which is a good thing.

        Perhaps we'll see less of:

        Title: How-to configure Foo
h1. How-to Configure Foo

...
h2. detail
h3. more detail

        1. Apr 15, 2008

          Adnan Chowdhury

          @Boots, @Alex: That was our thinking exactly. We're happy with having the labels on the bottom.

          This in no way means that we don't think labels aren't important by the way. We want to make labels far more useful, and the multiple label filter feature in 2.8 is a step in that direction.

          1. Apr 15, 2008

            David Dembo

            RE: the labels placement - I have to disagree that they were causing clutter... the labels line was only a few pixels wide, and a light shade of grey so as not to draw attention away from the content. As for the top vs bottom debate, I guess this depends entirely on the individual user, and the content in their wiki. For some wikis the labels may not be important in themselves as Boots suggests. In other wikis, they could in themselves be considered meaningful information in which case you do not want them hidden at the bottom of the page.

            For example if labels have been utilised as a 'flagging' system, or to indicate various 'statuses' (e.g. phases in a moderation workflow, etc), then having the labels at the bottom of the page is a clear disadvantage.

            However, I'd also argue that even in the scenario mentioned by Boots there could still be disadvantages. Even if their only function is to cross-reference similar material, less awareness/focus/usage of the labels interface overall due to lower visibility could cause issues such as incorrect or missing labels taking longer to be detected & corrected, etc - thus impacting the overall organisation of content in the wiki, or at the very least increasing administrative overhead (and I might add that decentralisation of administrative tasks is one of the overwhelming benefits of using a wiki as an information management solution, particularly in an enterprise environment).

            On a side-note - I know that the idea(s) I proposed above would be quite a big job to implement, but I'd like to point out that if such a system were in place we wouldn't be having this debate at all. (smile)

            On another side-note - has there been an official statement regarding this topic yet as Sarah mentioned?

  19. Apr 15, 2008

    Darren D

    Couldn't some of this snazzy interface development time been devoted adding a spell check function?

    That would be time well-spent! (big grin)

    1. Apr 15, 2008

      Bob Swift

      Disagree. We have had spell check support in FireFox for a long time. I think IE has add-on for that too. What does Confluence need to do?

  20. Apr 21, 2008

    Tim Eddelbuettel

    I wish me that the

    • Print Preview
    • Print function
      move to Tools.

    At the moment we have a Navigation Sidebar and the bar will be print (sad)

  21. May 04, 2008

    Sarah Maddox [Atlassian Technical Writer]

    Quoting a comment from "Anonymous" (Ben), which was originally placed on the Confluence 2.8 Release Notes on 2 May 2008:

    Hello,

    I really don't like the new Theme.

    Please consult a professional interface designer next time (release).

    The 2.8 release was a step backwards (typographically).

    The font-size-handling across browsers is just awful.

    Best regards,

    Ben

  22. May 06, 2008

    Heiko Burghardt

    The new UI is looking fine in most parts – some confusing issues have been already mentioned in the comments above.

    I just want to point out one more problematical issue that might appear on huge installations, especially, when hundreds or thousand pages have been accumulated in one space. Then, the new page move (drag&drop) is unusable. On a good-performing server system each tree takes minutes to pop up when clicking through the hierarchy. Dropping a page accidentally to a wrong tree means automatically a huge loss of time.

    From my point of view the tree is very nice for small spaces; but for huge ones it's no go. The users know where to put the page and the 'old-style' search function was great for them in this case. Thus, the facility to choose the function for performing the move would be great.

    (I hope that this function does not have a negative affect on the new page ordering function. I would be great to find a solution in the next release)

    1. Jun 12, 2008

      Stuart Gilberd

      Agreed - we have had several complaints about the new system.  Most of our spaces are pretty large

      1. Jun 12, 2008

        Sarah Maddox [Atlassian Technical Writer]

        Hallo all

        Please vote for this issue: CONF-11469 "Improve usability of page-ordering for large document spaces and accessibility".

        Cheers — Sarah

  23. May 21, 2008

    Bob Swift

    Per, can you give us an update on what the thoughts are on UI changes going forward and the timing? This will help upgrade planning for this year.

    1. May 21, 2008

      Adnan Chowdhury

      Bob, we will be looking at the RTE and Search over the next year. We don't expect to be updating the UI in a systematic way in that time frame like we did with 2.8. We want to let the 2.8 changes settle and build upon them in the short term. We will be doing a lot more UI cleanup in the meantime however.