The central value proposition is its reimagined UI, making threaded replies more visible and more interactive by separating conversation topics (threads) into different columns.
It’s currently just an MVP, but I expect to at least improve the UI and maybe rearchitect the system in the near future.
Thanks for the feedback -- definitely agree on the demo! Based on some feedback from one of the Show HNs, I'm planning to make some fake little chat bot, so users have something to interact with (albeit in a very scripted/formulaic way) instead of sending a link to a friend. The chat bot will replace the static demo entirely.
It's definitely a style change first and foremost. I got sick of this pattern: friend sends message1, message2, message3; I respond reply1, reply2, reply3. And then they probably reply to some (if not all) of my replies. Usually it's pretty clear which message corresponds to which topic, but it's always messy. With XpanXn, it's explicit and visually obvious.
Each topic column is a fixed width. You can pan around the chat canvas and zoom in/out exactly as you'd expect! In fact, another motivator was knowing that a lot of people like really small font sizes on their phones. This way, you tailor font size just by zooming in/out. There's definitely some opportunity to improve that, but for now, I think the ability to pan tends to most of that concern.
1. Threads aren't secondary. There's no secondary window, and threads don't get lost in the amalgamation of main window messages. All threads are presented equally, which brings me to...
2. It's visual. You see the entire graph -- how the conversation flows -- and you directly interact with the chat canvas.
I shipped an MVP of an instant messaging app that re-imagines the dynamics of chat. Your conversation is no longer limited to the vertical direction. It can expand in the horizontal direction to separate different but simultaneous topics!
I also did a couple of Show HN posts for it. Didn't get much traction with either, but it's ok because I think my next steps are to revise the landing page and get a more proper UI.
As someone who’s one week into a four-week gap between knowing there will be layoffs and knowing who exactly will be laid off, I completely agree. There’s some comfort in knowing that the layoff benefits are already defined, but they’re pretty bad for early career employees like me.
My nights are starting to focus on preparing for a job search.
Hey everyone, my name is Peter and I developed XpanXn ("Expansion") after wondering if instant messaging could better mimic real-life conversations if it were designed more like a mind-map.
XpanXn is an instant messaging app where your conversation is not limited to the vertical direction; it can expand in the horizontal direction to isolate different conversation topics being discussed simultaneously. Along with redesigning the dynamics of instant messaging, XpanXn also offers better privacy with no third-party data mining. You're the customer, not the product.
My intent is for this to be a minimum viable product. There's quite a bit of refinement needed to get XpanXn to realize its full potential and match the features we've come to expect from instant messaging apps.
I hope you'll give XpanXn a try -- no account needed. I'll be standing by to answer questions, and feedback is much appreciated!
Hey everyone, my name is Peter and I developed XpanXn ("Expansion") after wondering if instant messaging could better mimic real-life conversations if it were designed more like a mind-map.
XpanXn is an instant messaging app where your conversation is not limited to the vertical direction; it can expand in the horizontal direction to isolate different conversation topics being discussed simultaneously. Along with redesigning the dynamics of instant messaging, XpanXn also offers better privacy with no third-party data mining. You're the customer, not the product.
My intent is for this to be a minimum viable product. There's quite a bit of refinement needed to get XpanXn to realize its full potential and match the features we've come to expect from instant messaging apps.
I hope you'll give XpanXn a try -- no account needed. I'll be standing by to answer questions, and feedback is much appreciated!
I've been working on a chat web app for the past few months. Its defining feature is that it reimagines the way in which conversations flow, allowing them to be really nonlinear.
It's almost ready for a ShowHN. I just have to get the websockets working!
Sounds similar to some work I’ve been doing, so thanks for unknowingly validating my design!
At my employer, I’m spearheading a wholesale reimplementation of outdated process automation software, turning everything into Django web apps.
I’ve been working with a monorepo and monolithic deployments to maintain development velocity but recently started transitioning the CI/CD pipeline to deploy each application/service in the monorepo independently. The pipeline packages common assets (including, e.g., manage.py, common HTML templates, and the dependency spec...all housed in the same monorepo) into each app directory before the deploy stage.
Meanwhile, local developers clone the entire monorepo, and when they launch localhost, all of the services come online simultaneously. (That’s the goal, at least!)
I was already excited to see my work come to fruition, and now I’ll be keeping an eye on Khan Academy, too!
I've encountered this being used as a crutch for poor employee performance on a software project focused on replacing a legacy application.
An employee with little programming experience used his supposed lack of context as an excuse for poor work and disinterest despite having been given an overview of (1) what the legacy software does and why, (2) the broader project goals, and (3) the immediate project goal (i.e., replacing the existing software). The employee similarly hid behind their lack of technical understanding, asking questions to "learn" but ignoring the answers.
The author isn’t worried about the takeoff speed in that quote; he’s thinking about the increased duration of the flight as stiff winter headwinds (at cruising altitude) decrease the aircraft’s groundspeed.
Prevailing surface wind direction doesn’t vary much with season.
What is a better approach? I have Python that directly connects to an Oracle database, and the Oracle blog tutorial[0] for using their Python package always uses a cursor.
Great quote -- surprised I've never seen it before!
In my limited experience, it's a mixed bag.
Good: you get special treatment/opportunities because of a unique skill set and increased visibility on the end results of what you do.
Bad: management doesn't really know what you do between software releases, you're paid the going rate for your industry while SWEs make far more, and in-house software quality standards might not be established/followed.
> Gravity alone is unlikely to be able to accelerate a plane like that in such a short time
Yeah, a quick (and very elementary) back-of-the-envelope energy calculation shows that gravity alone couldn't achieve that speed. [SEE EDIT]
> Were the pilots desperately trying to go up, not knowing which way was up?
We'll have to wait and see, but it was morning, and I think I heard that there was weather in the vicinity of the crash but not at its actual location.
EDIT: That calculation was wrong. The aircraft had more energy at 5475 ft than it did at 3200, 7.73 seconds before the last data point.
Agreed, but it also had a groundspeed of 360 kts. Combined speed is then 463 kts. It's not impossible, but getting to that speed from 295 kts at a relatively steady 5000 feet...I don't know what to make of it.
One of my other comments on this thread includes a link to data that suggests that the aircraft's ADS-B transmitter was working until the end. The vertical speed transmitted by the ADS-B makes in-flight breakup believable, but how likely is it that the ADS-B would continue transmitting in that case? Not very, I'd guess.
Fun fact: Flight Levels are really only used at 18000 feet and above. That's where local barometric pressure is ignored and aircraft use the standard value. I believe it's a global standard to use local barometric pressure below 18000.
The granular data from FlightRadar24 paints an especially grim picture: a descent of 30,000 feet per minute (fpm) at about 400 feet above the ground. That seems like it might be erroneous given how high it is, but -16,896 fpm at 2500 feet seems plausible.