Is topnav a good idea, friendly user?

[RichardMPI]

When I look at the new help online for Flare, I am not convinced by topnav.

Search? Well, always useful, but only if you know what to search. And you can have pages and pages of results. That is not a main way to find structured information, I think.

No more panel of the side. Well, sort of, because the writers of the Flare help felt the need for a structured approach and put a minipanel on the right, like in this capture:
http://screencast.com/t/gxq9A1t4ecZ

If I scroll down, I do not see any more this panel, like in this capture:
http://screencast.com/t/D61QblYg1r

I have to scroll up to see the menu again. Is that better? I doubt it.t

Bu, in my opinion, there is worse. In the menu on the right, I click “Overwriting Documents” in the Framemaker section, I arrive here:
http://screencast.com/t/RneBnDNNihW3

As you see I get the information I need, but… where are the others commands about importing, from Framemaker? Gone. There is a Word import menu, instead. With the classic three-panes menu, It is very easy to see where I am and to click where I want to go. In this new design… What, I have to go to the previous page in the browser… Do you think that is really better?

I am confused by the new design.

Cordially
Richard

[jbkalla]

Richard, I'm also not sure it's an improvement, though I agree it looks a lot better. But that could have been helped with a bunch of nice skins, instead of the old-looking ones that you can download for Flare 10.

I would have liked to see an option to add the side menu (the true side menu that can be shown when the browser is resized to tablet-size) as a permanent option to replace the top-nav option, as I think it looks better than the old-style menu. It would be nice if I could show the side menu automatically, without clicking the "hamburger" button. I see why it's minimized by default, as the side menu is only supposed to be used for smaller screens, but the option to do otherwise would be helpful.

It would also be nice to see a few radically different skins for the new top-nav view. I know that super-advanced users will probably be able to modify the default top-nav formats for their own use, but it would be nice for less-knowledgeable users to have the option.

Just my opinions. But I'm old, so may be out of touch.

[sdcinvan]

I like the topnav as well. But I cannot authoritatively comment yet because I haven't implemented it. When I do (in about 8 weeks), I will likely make many customizations. I'll repost to this thread again.

[devans]

I decided not to use the Top Nav skin as there are too many heading levels in my output and it would take a lot of restructuring to make my manuals usable. Instead, I am using the new HTML5 Tripane skin. No, it's not as sexy but at least I know users will be able to find the information they need.

[HeraTech]

The first time I visited the Flare 11 Help I was completely confused. It took me a couple of minutes to figure out the new navigation paradigm. I certainly don't think it's intuitive as a Help system, although I could see how the format could be useful if you were generating output for a web page.

So far I'm finding the new top nav help to be difficult to navigate. It feels like the TOC has been reduced to what a new user would need. As an advanced user, I'm finding it hard to drill down to the nitty gritty details that I'm looking for. And the CSS does not resize to adapt to screen sizes, so even when I'm on a wide monitor, the content is takes up less than a third of the screen, the other 2/3s of the screen are wasted white space. Web page styles that only use a small column in the middle of the page for text are a pet peeve of mine, as I'm a fast reader, and when there is less text on the screen it means more scrolling.

Maybe I'm a dinosaur, but I really miss having the entire TOC and an index as navigational aids. One of the things that I try to avoid doing in my Help systems is hide content from my users, or make then go on a treasure hunt for Help where they have to click on a bunch of buttons as they hunt for the content they need. I feel like the new format hides a lot more than it reveals.

[BedfordWriter]

Still experimenting with it over here. So far, everyone I've shown it to likes the look of it. But, as others have noted, I am going to have to make some significant changes to my TOC before I install the result on anyone's workstation.

I think that Mark Baker was on to something in this article: http://everypageispageone.com/2013/06/1 ... avigation/ Google has trained us all to use search first and links second. The TopNav approach looks cleaner and a lot less intimidating than a tri-pane page.

I just wish that there was a way to generate an Index page. I don't need one that filters the way that the HTML5 tri-pane version does. I just want one page, filled with my index items in alphabetic order, each with an embedded cross-link to the appropriate topic.

[rob hollinger]

BedfordWriter,
You can create a topic and insert an Index Proxy in it and it will populate with your entire index. This can be added to the TOC for easy access by users.
Just be sure in the project CSS that you edit the MadCap|indexProxy style mc-output-support to equal ALL so it will work in web outputs.

[Nita Beck]

You can create a topic and insert an Index Proxy in it and it will populate with your entire index. This can be added to the TOC for easy access by users.
Just be sure in the project CSS that you edit the MadCap|indexProxy style mc-output-support to equal ALL so it will work in web outputs.

Thanks, Rob. Best new thing I learned today! In fact, I'll share this tip with my local user group which just so happens has a meeting tonight.

[BedfordWriter]

Tried it out, and there it is. Huh. Thanks, Rob!
I'd better post a follow-up to Dave's message in another thread...

[sdcinvan]

FYI,

There is a webinar coming up on the new topnav feature: https://www.madcapsoftware.com/demos/si ... 408Webinar

If you miss it, don't worry, MadCap records all their webinars for download. Thank you MadCap!

Some details:
Case Study: Goodbye Tripane, Hello Frameless Top Navigation Web Output

Time: April 22, 2015 8:00 am Pacific Standard Time (UTC-07:00)
Presenter: Paul Stoecklein, Documentation Manager | MadCap Software, Inc.

MadCap Flare’s new frameless Top Navigation output for HTML5 changes the landscape for online documentation, freeing you from the limitations of the traditional tripane format. In this webinar, Paul Stoecklein, Documentation Manager at MadCap Software, will describe this new type of output and discuss why it’s a big deal for content developers. Mr. Stoecklein will demonstrate how to perform a simple conversion from tripane to frameless Top Navigation in less than a minute. And finally, he will take you through the detailed steps he followed to convert Flare’s online documentation from tripane to Top Navigation with a fancy new homepage and context-sensitive menus. Paul will also include tips, tricks, and lessons learned along the way.

[BedfordWriter]

Trials are going well over here. I rebuilt my documentation to use top-nav and asked everyone in the company to use it instead of the tri-pane version.
All of the reviews have been positive. Everyone says that it's easier to find what they're looking for, and they like the look. Nobody can say exactly why, but they all agree that having the menu in the upper right corner is just easier to see and work with.

Still need to do a complete overhaul of my TOC before this goes to out to customers, but that was overdue anyway.

[chunkee]

Use bootstrap for your upper navbar. Much easier.

[StraygoatWriting]

Top nav is a good idea if you have a limited amount of content. For larger documents, with lots of TOC entries, it's just not very practical. What I would like to see is a tri-pane style TOC that has the look and feel of the top nav menu, but still scrolls and expands like the old TOC does.

I tried to create a left-side TOC with the new menu proxy and it worked fine. However, I can't figure out (yet ) a way of getting the div that contains the menu proxy to scroll and not exceed the height of the body div. The TOC is always a huge height because it is size to fit the entire contents in it. I can add an overflow-y to create the scroll, but suspect it needs scripting to get the max-height of the toc div to never exceed the body div.

When I tested the context-sensitive menu with clients they really hated it. They found it confusing, especially as there's no way to have a fixed 'home' option always at the top. But they also like to be able to see the entire scope of the documentation, which is a drawback of context-sensitive tocs. Interestingly, what my main client has asked for is the top-nav header, but with the tri-pane toc and body (and a footer I added on myself). Maybe MadCap could create a hybrid of the two that would work better?

Oh, and they were unhappy at the lack of options for customising the mobile menu too.

On the plus side, no more iframes

[ToddPh]

There are options for off-page navigation lists under Foundation, which I presume could be added into the TopNav skin. I have had good luck so far implementing some of the arcanery of Foundation within my Flare TopNav project, but have not yet tried the off-page navigation (slides into view from either side when you click the menu bar).

Has anyone had opportunity to try this yet?

Incidentally, I did discover one gotcha when including more functionality from Foundation. DO NOT use their JQuery version as it will break the Flare search feature and may cause other oddities.

[NorthEast]

There are options for off-page navigation lists under Foundation, which I presume could be added into the TopNav skin.

Yep, isn't Flare's responsive menu a Foundation off-canvas menu?

They found it confusing, especially as there's no way to have a fixed 'home' option always at the top.

There is a fixed 'home' option at the top, just click the logo.

[StraygoatWriting]

The 'logo' and the top-level menu entry both take you 'home' but it isn't intuitive in either case. Unless your logo says 'Home'.

People would need to learn how to use the help, and that's bad design in my view. Navigating the content should be easy and obvious.

[NorthEast]

Why not just add a item in the root of your menu called 'Home' ?

[StraygoatWriting]

Because the Root isn't always shown as far as I can tell. Once you get down to lower-levels, it shows the parent, siblings, children, but these don't necessarily include the Root. Unless I'm missing something (MadCap have raised a feature request for this, so I assume I'm not missing it).

[NorthEast]

Because the Root isn't always shown as far as I can tell. Once you get down to lower-levels, it shows the parent, siblings, children, but these don't necessarily include the Root. Unless I'm missing something (MadCap have raised a feature request for this, so I assume I'm not missing it).

The top nav menu in the header area is static though - it isn't context sensitive, so it'll always show the full menu.

I'm guessing you're talking about the menu proxy (component default skin), not the top nav menu. If you've set the menu proxy to be context sensitive, then yes you'll only see the parent level in the TOC rather than the full menu. You mention having a 'Home' option in another post though, so I'm not quite sure what you're doing.

viewtopic.php?f=9&t=21026&p=108433#p108419

I'm using the menu proxy as a navigational tool instead of the drop-down and have it showing the full toc. I just set it to show to level 3 and turn off the context-menu option (forget the exact name) in the menu proxy settings. In the end, I turned that back on though, as the full menu all the time became a bit cramped. I have put the top toc menu item as Home so it is always obvious how to get back to the start.

[StraygoatWriting]

Ah sorry, things got a bit confused there.

I have the top nav menu hidden because of the amount of content in the TOC. There's just far too many topics in the project to make the top-nav practical. But the client wants to keep the top nav header, and then have a sidebar with the toc in there. This is where I've used the menu proxy and hit the problems with the context-sensitive element of it - if you go down too many levels, it seems that you lose the root menu option. I've set the menu to show the full toc all of the time, to work around this, but that led to a problem with controlling the size of the sidebar that contains the menu so that it doesn't get bigger than the body. I've got a couple of proposed solutions to this from web developers, but haven't tried them yet.

[NorthEast]

If you look at the Flare 11 help, their top nav is a shallow 2-level menu that takes you to general topic areas, but the menu proxy on the right of each topic shows the full TOC in context sensitive mode. They talk a bit about it here: http://webhelp.madcapsoftware.com/flare ... ersion.htm

[StraygoatWriting]

But when the TOC is much larger than that, it doesn't really work that well (in my view). Everybody I user tested the context-sensitive menus with had the same problem - they felt lost in the content and preferred the old style, where they could burrow down into the content but still see the overall content easily.

I spoke to lots of web developers about this, and some of them suggested breaking up the menus into context-sensitive menus like in Flare, but others said accordion style menus would be better. I tend to agree with the latter.

Maybe it is just that I would like to see more web menu styles available in Flare? It still feels restrictive. I prefer your XML transform approach to be honest, as that gave us the bullet list which we could then manipulate any way we liked.

[NorthEast]

I prefer your XML transform approach to be honest, as that gave us the bullet list which we could then manipulate any way we liked.

I don't think you'd need to use the transform, as the menu proxy also generates a list. I'm guessing that you should be able to apply a third-party control to that, for example Smartmenus (which can display a menu or accordion control).

[StraygoatWriting]

I was hoping the list would be more accessible from the Flare UI. Like with the XML transform that you posted on your blog, Dave...where you get the ul that is the toc and then you can use that in whatever menu system you choose. I'm not sure how easy it is to get to the ul that is generated for the menu proxy (pre-build). Even then, you still have to do all the CSS (or otherwise) to create the menu styles from code, whereas it would be easier and more user-friendly to have interfaces for that.

[NorthEast]

I think it should be easy enough to apply your own menu plugin and styling to the output.

For example, if you have no menu skin in your project, the output will have a relatively unstyled menu, and starts with <ul class="menu"> which should be relatively easy to hook a plugin or styles to. Or you could set up a menu skin that has no formatting, and use that - which will be called <ul class="menu_skinname">.

I think I'd prefer to use the menu proxy as it's going to be part of Flare's build process, whereas if you used my transform it's a manual process to update the menu.