Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Launch HN: IcePanel (YC W23) – Onboard engineers with explorable system designs

news.ycombinator.com

Post reply on HN
Print view View original

61–70 of 75 posts

Re: Launch HN: IcePanel (YC W23) – Onboard engineers with explorable system designs

#61

Post by Terretta »

JacobShadbolt wrote: post #38
brickers wrote: post #35

Not sure if you’re intending this to be usable on mobile but I found some usability issues from a few minutes browsing on iPhone (I most definitely intend to have a proper look on desktop later - looks fantastically useful): 1- overlapping text/images in header; 2- list of steps was the first thing that was open - took me a minute to understand I could close that to get to the diagram; 3- I couldn’t work out how to z…

We haven't focused on making the editor mobile friendly as most diagrams are too complex for such a small screen - hence why it sucks on mobile. I'm sure it's something we could improve later on as an "on the go" mode, but for now it's not been a priority. Is there a use case to use this on a phone?

The iPad Pro 12.9 has a better (higher resolution) screen than most business users.

Re: Launch HN: IcePanel (YC W23) – Onboard engineers with explorable system designs

#62

Post by EarthLaunch »

Veuxdo wrote: post #13
ctvo wrote: post #3

Is the next step creating and updating these diagrams automatically? That dream seems to come up and die in cycles over the years, but it may be possible now depending on the compute platform and network appliances you use. This push to automate by doing interesting things, like reading your network traffic ( https://www.akitasoftware.com/ ), could work here. I'm unsure, as is, how you fix the organizational and huma…

> I'm unsure, as is, how you fix the organizational and human problem: It takes effort to initially create these diagrams, and constant work to keep them updated as systems evolve. How do you make that easier? This is one of my primary goals with Ilograph[0] because, as you noted, diagrams that are hard to maintain don't get maintained (and very quickly lose value). It takes a three-pronged approach to solving it: 1.…

I finally got a chance to try this, and I'm impressed. I love the interactive examples right on the site. I'm coming from Mermaid[0], which falls more under 'pure diagramming', where as this is...systems diagramming. Thanks for sharing it.

0: https://mermaid.js.org/intro/

Re: Launch HN: IcePanel (YC W23) – Onboard engineers with explorable system designs

#63

Post by mattste »

eximius wrote: post #51

Wow! I absolutely love this! I will have to try it! Better C4 tooling has been something in the back of my mind for a while and this looks pretty polished. I do have some concerns on pricing. $30-40/editor/month is pretty steep! Unless there are good tools for managing swapping users in and out of "reader" vs "editor" states across billing cycles, I think a lot of orgs will balk at this pricing. I know mine will if 9…

I came here to echo the pricing sentiment. I just encountered this problem and documented my company's architecture using Whimsical. I felt it was lacking.

We're a <10 person start-up. $40/mo seems too much relative to how often we'd use the tool. I would use this tool if there was a cheaper option ($10/mo/editor) for a team of our size.

Re: Launch HN: IcePanel (YC W23) – Onboard engineers with explorable system designs

#64

Post by silasb »

victor96 wrote: post #8
ctvo wrote: post #6

Earlier quoted context omitted.

I'm not sure I understand. A system diagram from source code or infrastructure alone is difficult, but adding some constraints and boundaries may help? What if we only cared about http based services and the boundary is at the service layer? A sidecar running alongside your deployed service keeps track of incoming and outgoing network requests. Each sidecar is configured with metadata: The service name, hierarchy --…

Yeah that makes a lot of sense, we definitely believe there are automated ways to help speed up the modelling/diagramming process. Such as automatically populating certain levels of the model from resources in reality as you described. Possibly integrating with something like backstage.io could also be super interesting. Then you can create diagrams quicker from a pre-populated model.

+1 for backstage.io. This is something that I hoped the backstage graph would evolve into...

Re: Launch HN: IcePanel (YC W23) – Onboard engineers with explorable system designs

#65

Post by Terretta »

As a customer since 2021, is this re-launch HN?

Loved the concept, found it fell over for real-sized things on even the most powerful machines, had to switch to Structurizr to do our C4 modeling: https://structurizr.com/

Was very disappointed, bet I'd get more devs to model architecture with this tool. If it's relaunching because perf problems were resolved, will look forward to try it again.

Depending on scope of people's needs, either highly recommended or, try it first.

Hats off to Victor for great support back then, and I see the docs are a reflection of that, like this section on embedding into popular tools:

https://docs.icepanel.io/features/sharing#embedding-share-li...

TL;DR: Helpful team, thoughtful UI, thoughtful docs, a product capability (c4 modeling) very worth understanding and using.

Re: Launch HN: IcePanel (YC W23) – Onboard engineers with explorable system designs

#66

Post by victor96 »

Terretta wrote: post #65

As a customer since 2021, is this re-launch HN? Loved the concept, found it fell over for real-sized things on even the most powerful machines, had to switch to Structurizr to do our C4 modeling: https://structurizr.com/ Was very disappointed, bet I'd get more devs to model architecture with this tool. If it's relaunching because perf problems were resolved, will look forward to try it again. Depending on scope of pe…

Thanks for your response, sorry to hear you moved away due to performance limitations.

We've been working hard to improve our performance/scalability for large models over the last couple of years. We shipped major updates in this area recently so I'd be interested to hear when you last used the tool.

I'd love to dig into what issues you had so we can make sure they're resolved for you/other people.

Please reach out to me at mail@icepanel.io

Re: Launch HN: IcePanel (YC W23) – Onboard engineers with explorable system designs

#67

Post by neodon »

I love this! It's exactly what I've been looking for and checks some boxes for things I've needed for a long time in a modeling (vs diagramming only) tool. I discovered C4 a few months back, so finding that it has C4 support is awesome.

Would you be willing to elaborate a bit on what frameworks, tools, and technologies are used to create IcePanel? Anything you're willing to share, and specifically I'm curious if you used React Flow.

Re: Launch HN: IcePanel (YC W23) – Onboard engineers with explorable system designs

#68

Post by victor96 »

neodon wrote: post #67

I love this! It's exactly what I've been looking for and checks some boxes for things I've needed for a long time in a modeling (vs diagramming only) tool. I discovered C4 a few months back, so finding that it has C4 support is awesome. Would you be willing to elaborate a bit on what frameworks, tools, and technologies are used to create IcePanel? Anything you're willing to share, and specifically I'm curious if you…

Awesome, let us know if you have any feedback on the tool.

For the canvas we use https://pixijs.com, it's super powerful/performant and works well for us.

Re: Launch HN: IcePanel (YC W23) – Onboard engineers with explorable system designs

#70

Post by Mandatum »

As a consultant, I love this.

As an employee however; nobody on my team, nor my projects, nor my wider organisation will spend the time to keep these updated.

We can barely keep public-facing API documentation up-to-date. Diagrams like this are an order of magnitude harder to keep up-to-date, and Solution Architects will refuse to go to this level of detail, as they'd actually have to think through the problem and do some actual system design.

But as a consultant, I'm going to use this in my kick-off projects and my proof-of-concepts, and it's going to dazzle everyone. But maybe 5% of my clients would pay me to do detailed diagrams or documentation like this.

EDIT: OK, unfortunately the initial onboarding is overwhelming and underwhelming at the same time. I'm used to ArchiMate, I'm used to draw.io, I'm used to Visio, I'm used to plantUML. You've taken some of the existing design patterns but made them different enough it feels uncomfortable.

The initial onboarding needs significantly more work. Dumb down the default, initial view. I don't need "Start Trial", I don't need "Help", I don't need "Invite", I don't need "Embed", I don't need whatever the fuck "Landscape recommendations" is, I don't need wait what the fuck is "Link to reality" and how is it different to the "Share" part of "Embed and Share"? Why is there some sort of animal I can't make out with a party hat on it next to it? Oh Link to reality is a "fun" play on syncing with a backend repo.

Post reply on HN