Yeah. As a high schooler I just wanted to use AIM on it, but all the web-based AIM clients required Flash at the time, which wasn't supported in the PSP browser.
So I ended up hacking together a site called AIMonPSP with PHP and MySQL that did all the AIM communication on the server instead of client-side. Made a decent amount of money (for a high schooler) on AdSense banners, and learned a lot about software design the hard way.
Started on a VPS and then scaled to a single larger dedicated server through a hosting company. It was never doing crazy amounts of traffic, maybe 1-2k concurrent users at peak, and the frontend was just doing slow polling every few seconds.
The m5stack dial is just a screen with rotary input ring, but doesn't have haptic feedback. They actually just launched a new product the roller485 or rollerCAN that in theory is a nice off-the-shelf BLDC haptic knob, but I haven't had a chance to play with mine yet
Oh, hi, creator of the SmartKnob (mentioned in the article) here - I'm continually blown away by how much UX discussion it has generated over the years!
One of the things I regret a bit about the prototype and demo I originally shared is that I used a press action and the screen as a modal/menu interface. The screen makes for a snazzy demo video, and works great for interfaces where you have the user's full attention (like a smart home control panel) but I think there's a lot more potential for just the haptics, paired with other dedicated buttons to switch to specific (i.e. not a menu of) modes, like this later demo I built using the haptic feedback for a video timeline jog tool: https://youtu.be/J9192DfZplk
The smart knob you made is genuinely one of the best hardware creations I have ever seen. I only wish that I was creative enough to think up good uses for it so that I could put it to work, lol.
Haha, I've built at least 5 of them and my problem is that I enjoy the hardware/design portion as a hobby, but writing the software to put them to use feels too much like my day job, so I haven't actually done anything too useful yet...
I was just thinking about this while checking out the Seedlabs page.
Because now it is somewhat commercially available, and a lot of people (including myself) that previously weren't thinking of having this just because of the hasstle of assembling it themselves, can now consider buying a pre-made unit and play around with it.
I was thinking that it'd be REALLY GREAT if there was an easy way of making "apps" for this smart knob. Kind of like watchfaces or pebble apps. Anything to make it easier for people to play around with this. Maybe a lightweight SDK or something.
I'd be more than happy to contribute to such a thing, but doing this alone is too daunting of a task.
Side note, the 245 EUR price by Seedlabs is equally daunting :(
Your knowledge seems practical and fairly deep to me. I loved electronics so I got an electronics degree and I ended up with an irrational antipathy towards electronics since then. Got a software job instead which turned out to be a great career (compared with most of the electronics guys I know).
I am actually also enjoying the critical thinking about UX that is stemming from this design.
I'm starting to feel that full software modifiable screens are not the "new age" of in-car experience, but a v.01 of highly customizable, highly complicated settings control; a lazy first implementation. What we are seeing with your design is more of the refinement of the concept. So, kudos to you!
I concur with many people that this might still not completely cut for "eyes-free" usage which you need while driving a car. But for a lot of applications, it's a way more premium/refined interface. I'd limit the number of options on the main menu to 5 and already you've reduced the number of buttons from 10 to one knob.
On the note of just using the haptic feedback: did you compare things to the surface dial? I really expected that to gain more "mainstream" traction, but it seems to have fizzled out.
There’s a commercial product that looks like a fancy fancy version of this and I think has a tilt sensor as well.
It’s notable not just because it is loved by some media people, both art and video, but also because it’s shown up on the pilot’s chair in several notable sci fi movies/series with an outer space theme.
I do want more smart devices with analog inputs and outputs though. I feel like Ambient Technologies were onto something but never found the market fit I hoped they would find.
I've used it for 3D CAD and seen it on The Expanse as part of the bridge crash couch props on the Martian vessels. They also used an older model of Black Diamond headlamp for the space suit lights in early seasons. There's a balance to be struck here - too much reuse of modern objects and it pulls you out of the action. I think the Expanse did it well.
It's funny how you mostly just notice the objects you're familiar with. If you look at the prop auctions you see all kinds of "regular objects" integrated into props and sets. Sometimes the really obvious ones mean that particular props have to be shot from certain angles (you don't generally see the bottom of a crash couch for a reason!)
JSTOR was explicitly a library of public domain works, consolidated in a single place so that academic libraries could access those papers that nobody had an interest in distributing anymore.
It recently added a bunch of copyrighted journals. It didn't have any of those at the time.
I re-read the MIT report by Abelson and it looks like JSTOR was an archive of old scientific articles from many journals, most of them still under copyright by the journal. I'd need to see more evidence that it was public domain.
Hmm this is really different than my experience with a 2018 Crosstrek, so maybe things have changed? When I bought it, Subaru was among the earlier CarPlay/Android Auto adopters (we specifically ruled out a new model year Prius because it lacked it and we couldn't wait a year to replace our totaled car just for CarPlay/AA), and other than a very rare issue where the head unit screen doesn't turn on, it's been pretty rock solid with both phone OSes.
Environmental controls are all physical hardware, CarPlay/AA is integrated well, etc; I can't really complain about any UX in the car.
The only UX gripe I can think of is that Apple doesn't let you use natural touch inputs to pan/zoom a map (instead forcing you to tap to bring up on-screen d-pad, then keep tapping the tiny button targets while trying to keep an eye on the road), but that's entirely on Apple; Android Auto allows normal 2 finger pan/zoom, so it's not a Subaru problem.
I have a 2018 Crosstrek and a 2024 Outback. They both are really, really, good, and here are the two rough edges.
* Crosstrek doesn't do wireless CP/AA, and the USB only supplies 1.5a, so it sometimes isn't enough to charge the phone while listening to music and navigating. This is a common problem in 2018 vehicles. USB-C had not conquered the world yet.
* Outback has a big screen. The only complaint is that it is too aggressive, telling users no because the vehicle is moving. Passenger operating the touch screen is a thing, and nothing is worse than having to pull over so someone can change a setting. Also, it is a very bad experience to be going 70MPH, tap a button, and be told no - will be interesting to see if this causes accidents where people momentarily stop paying attention to the road because they are raging to the touch screen.
One thing that is really nice about Subaru is that the controls just evolve a little from model year to model year. When I got the Outback, there were only a few buttons that had moved to get used to. Aside from climate control, almost everything has buttons, and most of the time, they are on a stalk or steering wheel.
There is no cure for digital privacy in any modern car. And there is no consumer choice to enable or disable data sharing. We need some legislative intervention here.
I noticed that too with CarPlay. Trying to pan around in Waze is impossible but doing it in Android Auto is very easy. The one nice thing about CarPlay Waze is that it allows keyboard input, Android Auto (at least in my Subaru) only allows for speech to text when searching locations.
It's something about how they have it configured. I have a '17 Honda Civic and its built-in CarPlay lets me pan and scroll just fine. However, on my '23 Ascent, I have to tap arrows to pan the map, and vertical "scrolling" is actually just pagination. Same iPhone, different behavior. It must be some simple config toggle on Subaru's end that they left off for whatever reason.
i believe it is related to the capabilities of the touch screen itself. something like "if no multi-touch available, fall back to the pan/scroll interface" makes sense to me.
CarPlay supports pan gestures based on configuration provided to it by the car maker. This is entirely on Subaru for misconfiguring their CarPlay integration.
Top speed, sure, but for typical commuter heavy-rail, a non-express train isn't running at top speed for all that long.
Diesel-electric trains take a LOT longer to accelerate compared to a modern EMU, so much so that Caltrain's electrification project shaved 23 minutes off the SF to San Jose local trip, from 100 to 77 minutes.
Videos [0] [1] make the acceleration improvement pretty clear.
The MBTA already runs top speed on most of its lines once you get outside of roughly I95 depending on the line. Getting there faster would help but I don't think it would shave as much time off the end to end trip as you think. And for the urban stops they already accelerate and brake at the limit of what is reasonable for standing passengers. They can't push it too much or an old lady is gonna bounce off a wall and get a nose bleed and that's a bad look. It's not like Acela where a ticket guarantees a seat.
There will definitely be some improvement from electrification but I don't think it will affect median travel times much and the affect on average will mostly be from reliability.
The Fitchburg line did do upgrades a few years ago. I think they double-tracked sections that weren't. It still take a while--hour+--from the outer reaches.
Not enough seats is mostly pretty close into the city in my experience. At least on the line that I sometimes take, it's mostly Waltham in which doesn't have a mass transit line.
This is super cool! As a regular BART commuter I always thought it'd be fun to try and build a location classifier based on the screeches in different tunnel locations, but using accelerometer data is probably much more practical.
Using the microphone as a sensor is a bit of a no-go a transit app. You could just record the noise of the train rolling to find out the movement, but your users will suspect you are listening to them.
I'm building a collator robot [0] to help me pack items I sell for building your own open source split-flap mechanical display [1].
I get custom character flaps printed and die-cut in bulk and then sell them in smaller sets. A full set of flaps for one module has 52 distinct designs (letters, numbers, symbols, etc) and I get them from the manufacturer grouped by design, so they need to be collated to sell as packs of 52 with 1 of each design.
My WIP robot will take a stack of one design and distribute them to a bunch of cubbies, then I'll swap in the next design, and so on, so each cubby ends up with a full set.
It's based on a cheap ~$110 CNC gantry frame from AliExpress and a ~$35 BTT SKR Pico 3d printer main board running GrblHAL. To detect whether the flaps feed successfully I use a visible light break-beam sensor (the typical IR sensors don't work because the PVC flaps happen to be IR transparent!) which acts as the "z probe" - the flap is fed via a G38.3 probe action which returns whether the probe was successful or not, and the "z" coordinate it was first detected.
I have a python script running on a computer to send the gcode to the machine.
Please keep up the great work on this! I love this split flap project. It's gotten me into electronics. I haven't had the chance to build it out yet, but I want to put together a sign as a project.
And perhaps more to the point - you USED to be able to use normal Java file apis and syscalls outside of Java, but that functionality has been gradually whittled away (in the name of legitimate security improvement) over the years, meaning "basic" IO functionality your apps relied upon could be taken away at any point and replaced by less ergonomic Java-only APIs with less functionality.
Fun fact: the official Dropbox Android app used to use inotify to watch for changes to the publicly writeable synced files in order to sync back to the cloud! Had to be replaced by java Storage Access Framework APIs later.
Another fun fact is that the Android sdk came with a JNI wrapper around inotify but it buggily stored inotify handles in a static (global, within an app vm) dictionary, meaning you'd silently lose tracking if you created more than one Java file watcher object that happened to be for the same path, so I had to rewrite that JNI wrapper back in the day to avoid that global state bug.
So I ended up hacking together a site called AIMonPSP with PHP and MySQL that did all the AIM communication on the server instead of client-side. Made a decent amount of money (for a high schooler) on AdSense banners, and learned a lot about software design the hard way.