Sitemap (feature request)

[Cedric]

Hi.

Not having found a topic dedicated to all feature requests, I post this here.

The main reason why I don’t use the Flowmapp sitemap tool is the following: the current representation is great but takes up a lot of space, even without the thumbnails.

I’ve attached an example.
The branches “Main Topic 1” and “Main Topic 3” use the FlowMapp representation.
The branch “Main Topic 2” uses a more compact but just as efficient representation.

You’ll probably find like me that the representation used for branch 2 will save a lot of space and provide a more efficient helicopter view.

I love your tools. I’m a big fan.
But unfortunately, I’m working on very big projects on a regular basis and the representation is a real pain. I had to stop my subscription at Flowmapp and regret every day having to work with another tool.

Maybe you could allow the user to choose the representation that suits him best?

Thanks for your sharing space, anyway.
It’s an excellent initiative.

Have a nice day,
Cedric

PS: May I suggest creating a topic structure for each of your products? (sitemap, persona, CJM, …)

[Nick]

Hey Cedric!
First, thank you very much for the feedback!

Well, we got you and we think that your request has total sense.
Helicopter view is for a long time in our plans, so, here is the quick look on our draft for that.

Please note, it’s not the final version (probably), and we have no ETA from devs on it.

And, well, not gonna lie, it’s kinda sad that you stopped your subscription, but it’s still in work and we would really appreciate if you can tell your opinion. What do you think?

Nick

[Jaycee]

I’ve exactly the same problematic on big projects ! I hope this view will arrive quickly

[Cedric]

Hey Nick,

I want to apologize for not answering earlier.

First of all, thank you for your enthusiastic response and proposal.
As a user, it is nice to feel listened to. Even though I suspect that a product roadmap is defined beforehand.

The proposal made here seems to be a good basis.
I think that the margins between the parent and child topics (and/or siblings) should be adapted so that we can better feel the levels of filiation.

When I present a sitemap, I always start from a version where the branches are not deployed and, gradually, I deploy the branches and show the relationships between topics… This leads me to think that besides the possibility of having a view with fewer details (in order to keep this helicopter view principle), it will probably be useful to evaluate the interest of a feature allowing you to choose how many levels you want to display at the same time…

As a UX designer, I’m turning to anyone interested in this feature… do you have similar needs? Other needs?

I look forward to continuing to discuss them with everyone.

Cheers,
Cedric

[Nick]

In progress

[Cedric]

Keep us posted.

[Nick]

Cedric!
Glad to hear from you!
Please no worries.

…I suspect that a product roadmap is defined beforehand.

This is an absolute truth, but we always try to tune and adjust the roadmap according to the feedback we receive from users. I mean, of course, we have our vision of what our next feature should be looks like, or what it should be. But if we receive a lot of requests for something that we planned on afterward — there is a big chance of reconsidering our plans.

The proposal made here seems to be a good basis.
I think that the margins between the parent and child topics (and/or siblings) should be adapted so that we can better feel the levels of filiation.
When I present a sitemap, I always start from a version where the branches are not deployed and, gradually, I deploy the branches and show the relationships between topics… This leads me to think that besides the possibility of having a view with fewer details (in order to keep this helicopter view principle), it will probably be useful to evaluate the interest of a feature allowing you to choose how many levels you want to display at the same time …

Makes sense.
We’ll need to discuss it and think about your vision.

[cndcc]

This feature would be AMAZING as my team has run into multiple problems with large sitemaps (for example, for a large healthcare intranet where we MUST include the departmental structure for the organization to show to developers).

Take for example this sitemap we have, at a whopping 48,000px width, in a case where the client cannot or will not view it through Flowmapp for review (claiming it is too “foreign” for them to view in, even after you provide instructions on how to use it, and tell them they’re going to have to scroll a lot anyway no matter how they’re viewing it).

1. Exporting problems: The sitemap gets so extraordinarily long that we are unable to export (the width of the image is not so much a problem as the size of the file). Well, you can export — but the image is literally too wide for the native Mac image previewer to view the image. You get a mini blue screen of death in Image Preview (see below). You also can’t import it into Photoshop/Illustrator at that point to then convert it into a PDF for a client because it’s simply too wide of an image, so those options aren’t even available. No matter what file type it is, it’s too wide for the Image Preview to even render it, so we can’t pass that off to a client. If you use an online converter to successfully convert it to a PDF, you will get a “ran out of memory” error when you open it.

2. Disorientation in navigating: When you collapse a LARGE branch in the sitemap, you lose your place in the sitemap and literally cannot scroll back to the center of the sitemap or to where you were before, forcing you to refresh the browser, as where you were before apparently goes off into another galaxy (You can see we’ve already removed the sitemap thumbnails to save space, but this doesn’t help much in a horizontal view).

Uncollapsed:

Collapsed, unable to scroll back anywhere:

A solution to this would be having the screen follow where you collapsed your branch, or having a (possibly hideable or collapsible) navigator pane like in Photoshop or Miro.

3. Forced recall vs. recognition: In large sitemaps, where you have difficulty searching for a certain card/page, the search is practically useless if you want to know where in the sitemap it is. The sitemap does the disorienting thing of makes everything else on the sitemap disappear except for your search results, completely eradicating any sense of recall/trace as to where that card lives in the hierarchy.

For Example, I have “Research” under several different branches due to the nature of the intranet. How am I supposed to know what the parent branches they belong to? My only solution is then to assign a label to the card I’m trying to hunt down the parent branch of, using the label filters to flag it and then removing the label once I find it, which is a messy workaround.

Solution: Provide two options for search results:

1. Allow the entire sitemap to be shown while greying out the pages that are not included in your search query - sort of like how when you filter by a label in Flowmapp.
2. Entirely hide the pages not included in your search query like it currently does.

This way, users have the option to at least see where they’re at.
You could also provide a breadcrumb reflecting the card/page’s place in the hierarchy when you click inside of the card.

The tree view is the most helpful view we have in large sites like this, but it’s a feature that is designed as more of an afterthought.

I understand a lot of sitemaps aren’t this extraordinarily wide, but coming from a user experience background, the consideration and testing of edge cases are just as important as main use cases (small sitemaps). Any billable time spent way-finding in the app or troubleshooting is valuable time wasted.

We’ve been looking for the perfect in-between of free-form apps (Figma) and structured apps (Miro) for designing maps and flows, and we thought Flowmapp was going to save us a lot on time on such a heavyweight project, but I can’t tell you how many times these issues have frustrated us.

Very excited that the helicopter view feature will be released soon, and looking forward to it! However, we hope that you can resolve these issues in your app.

[Nick]

Hey there cndcc!
Apologies for the late response and thank you very much for the ideas!

So.
First of all, I would like to note that developers are aware of the problem with very wide Sitemaps and all the consequences that are coming from it. Like, problems with export, for example. We’ll make some changes and upgrades.

Well, you can export — but the image is literally too wide for the native Mac image previewer to view the image. You get a mini blue screen of death in Image Preview (see below). You also can’t import it into Photoshop/Illustrator at that point to then convert it into a PDF for a client because it’s simply too wide of an image, so those options aren’t even available.

Hmm, what is the size of such a file? Did you try to export in SVG? What are the results?

Disorientation in navigating: When you collapse a LARGE branch in the sitemap, you lose your place in the sitemap

Makes total sense.
We think it’s a great solution for the problem to have a navigator pane like in PS/Miro.
Added to the backlog!

In large sitemaps, where you have difficulty searching for a certain card/page, the search is practically useless if you want to know where in the sitemap it is.

Makes total sense [2], but this time we actually discussed this before! It was before we decide to add Personas and CJM and eventually, it goes into “for the future” folder

I understand a lot of sitemaps aren’t this extraordinarily wide, but coming from a user experience background, the consideration and testing of edge cases are just as important as main use cases (small sitemaps).

We absolutely agree. Our goal is to create flexible tools that work fine and provide a good user experience no matter what your requirements are.
The main obstacle here is the harsh reality - FlowMapp is the small team of enthusiasts. We just don’t have enough resources to make everything we want asap - we have to choose and plan.

I can’t tell you how many times these issues have frustrated us.
Very excited that the helicopter view feature will be released soon, and looking forward to it! However, we hope that you can resolve these issues in your app.

Sorry about this. You have no idea how grateful we are for such detailed feedback and your - participation, you obviously spend so much time creating this post

Please check your PM!

[Hopscotchdesign]

Hi there. Is this functionality available yet? It’s essential for big sitemaps.

Thanks.

[arielrey]

Need this as well!

[prue]

Hello there
I love your product, but yes - looking for this feature. Do you have an update on when it will be available?
Thanks

[bet8kor]

Sitemap (Feature Request): Enhance your betting experience with Bet8 - the go-to platform for 해외배팅사이트. From diverse sports options to exclusive casino games and a vast array of slot machines, Bet8 stands out for its variety and user-friendly features. Explore the best in online betting with low rolling conditions and enticing bonuses. Your ideal playground for safe and enjoyable betting awaits!

[herbalshotz]

Enhancing the HerbalShots experience with a new sitemap feature for seamless navigation and accessibility.

[gemoyangka]

Enhance user experience by implementing a 'situs slot’ focused sitemap, optimizing navigation for seamless exploration of slot-related content.

[Nathan]

I’m surprised this view has not been prioritized yet. Is there a roadmap that is shared or expectation on when this could be released? It’s quite a critical decision point for tool evaluation.