ckz

I'm a native English speaker/~B1 French speaker trying to very intentionally create a bilingual household environment. It's not pure immersion, but I can (and do) narrate what I'm doing for most daily activities in French, read aloud in French, consume French audio, etc. All much to the bemusement of my own French mentor, who's validated that I'm not instilling a terrible accent, but is also getting peppered with questions in my search for French children's literature.

What made you choose the software track this time around?

My first internship was as a designer, then I freelanced for them as a dev, then when I graduated and it came time to join full-time, I was asked to pick one track or the other. :)

HTML & CSS seem a world apart from traditional programming (and computer science, etc.) and were initially much more about things that were the designer's realm--another tool for layout, format, hierarchy, etc. I remember so many frustrated PHP et al. devs who really didn't love writing HTML being thrilled when I would ask to contribute to the UI layer of a given CRUD app. I was happier doing it that way too (still am).

Javascript--especially before being engineered into its current oblivion--was fuzzier territory, but I'd advocate that it should be a shared responsibility between the designer and [back-end?] developer, meeting somewhere around accessing the API.

The ability to both design and implement the interaction layer of a website or application is a superpower and, on average, results in a higher-quality product. The current division of labor makes for weird silos and loading spinners everywhere that one layer of responsibility ends and the next begins.

Note that this is the path I took and prefer (dev who designs; designer who devs), which I suppose makes me both less-common and very biased towards it. :)

My dad set me up with it + his notes from an incomplete attempt around age 5 or 6 and I probably didn't beat it until 7 or 8 (and continued like this for the next few games).

Here's my theory for a game like this vs something that's pure "learn to code/draw": Give her a world to explore that builds the -drive- to create.

I like Myst as a starter because:

1) It's unhurried. I wandered for a year learning what elements in each environment were interactive and slowly making sense of the puzzles. You -have- to simply explore and figure it out.

2) The worlds in it are masterpieces of art and creative thinking. Visually, it remains very engaging (the later games even more so) and you can tell it was a labor of love by a small team (particularly 2 brothers). Just as with books or nutrition, you want you and your children to be consistently exposed to the best of a given subject because that sets the imagination churning on what's possible and starts the process from a high bar.

3) It's a clever way to encourage familiarity and use of professional digital creative technologies (computer, mouse, etc.) rather than building additional affinity for touchscreens (which will happen naturally). Obviously you can create _a lot_ on a phone/tablet, but there's just more junk food around and it's easier to limit sources of temptation/mediocrity rather than fight them. I'd rather train my young child's willpower and self-regulation on easier opponents than modern apps, streaming, etc. :)

tl;dr- Anecdote of one: I consider the Myst series to be an important early step in my eventual journey into creative work and entrepreneurship (high school) and later a hybrid career in design/dev more broadly.

Link: https://www.gog.com/en/game/myst_masterpiece_edition (there are also newer 3D re-releases which retain most of the qualities of the original, but I think the values above are best expressed through the static scenes of the early editions and that, at 7, the new-shiny is missed less).

^ If you skim past the whatever was up with the Win7 reviews, you'll see my sentiments echoed -a lot- in the reviews. :)

* Westinghouse desk fan. Tanky and moves a ton of air because it has essentially no grill, but I do have it on a kill switch to protect little fingers.

* As @zamnos mentioned, radio. I have several consumer receivers and amateur transmitters from the period. These fall less into the "best" category for obvious reasons, but are more for kids' historical context. I'm exploring arcane combos like a cassette player + tiny AM transmitter + antique radio. Sort of a [mono] stereo with a non-all-you-can-eat music library combined with experiencing the physicality of RF propagation. Also they have standard 1/4" headphone jacks!

* Many books around that age. Tom Swift, Oz, etc.

* A few kitchen gadgets like an electric waffle iron and a hand grinder (I do have modern ones too).

Getting that working up is on my to-do list. Today I use some Python scripts to read engine codes and such, but it's not like I always have my phone or laptop on me. :)

The thought process for the purchase was that I wanted a standalone DAP without a touchscreen (iPod-esque), without wireless connectivity, with expandable storage, and not running Android. The M3K also has good Rockbox support including dual-boot, so I swap between that and the native Linux firmware at times.

I am considering getting a second device of some kind with Bluetooth because there are occasional but persistent times where it honestly would be nice. Ideally it'd still be running a pretty basic OS, though.

On Linux there's pilot-link (command line) or J-Pilot (GUI on top of that). I don't love the UI for J-Pilot, admittedly, which feels a little rougher than Palm Desktop. A Windows VM is also a common approach.

For devices, there's a dividing line between 68k and ARM.

A 68k will feel more "classic" and will often get you things like AAA batteries and LCD grayscale screens with a bit of an e-ink vibe. Some models like Handsprings are expandable with more "modern" (for 2001) capabilities like extra storage, a camera, or GPS. Some Palm/Sony devices have SD slots too. Most devices of this age involve feature tradeoffs, however. You'll often find color, or AAA, or 16MB of RAM, but not all 3. For a 68k daily driver, you probably want something running OS3.5 or OS4 to avoid the limitations of the super early versions.

ARM models (Tungstens, various Cliés, Treos, etc.) close the gap with smartphones much more--and some literally were. Color, higher resolutions, lithium, media support, SD, bluetooth, wifi, etc. These run OS5+ and having ARM under the hood unlocks an additional class of apps the older ones can't run.

A reminder also to definitely tune one's expectations to the era. Truly modern connectivity requires fiddling and having no-to-rudimentary HTTPS support can make these feel more disconnected today than they originally were. Still, you might also be surprised at how many daily tasks today were achievable 20 years ago in a way that's generally familiar to us now.

Definitely meant the positive version and I have no idea how I transposed those two! Apologies for contributing to the mess and appreciate you catching it. :)

I do own some, but they don't get used for much (browser-on-the-go, mostly).

Smartphones are definitely better all-rounders, but what I've come to adopt in recent years is a hobby of finding whatever tech/concept seems "best" to me (from any period in time) and then using that. Sometimes that means hardware from 1920, sometimes from today (e.g. I have a current-gen GPU to join the AI arms race). Sometimes that means a modern evolution of the concept without losing the spirit.

Easy examples:

* iPod -> Music player w/ FLAC + 1TB SD

* Gameboy -> Analogue Pocket (or sometimes original hardware)

* A modern standalone camera, etc.

It's sort of like living in the dream version of 2002 where tech stayed hopeful and fun (not sure if that's good or bad). Definitely brought me the most joy in tech I've had in years.

PDAs (and a _lot_ of tech from <2010) have the advantage of still being built entirely to serve the user. For my needs, I basically view it as day-planner or complement to a notepad and don't expect it to be a smartphone. My opinion is that these devices basically "solved" the digital calendar by ~1999 and that almost every calendar feature since (except maybe sharing) usually serves some other business need in addition to the user, or is just clunkier.

A PDA just wants to take good notes, manage the day's work, and be a simple extension of your mind. Most modern tasks (that don't require a network connection to be useful) have apps that still exist and don't spy on you: Food journals, encrypted notes, flashcards, project management, ebooks, cached news, Wordle, period trackers...

So, if your life today doesn't _depend_ on a specific vision of modernity, you don't miss out on much of it while benefiting from some forgotten UX benefits: Offline-first, great UI, week-long batteries (AAA if so inclined), Graffiti input, etc. :)

He also contributes regularly to apps the community is developing, teaching us hobby devs new tricks. :)

As someone who still uses PDAs regularly, I can't express enough gratitude.

Philosophers have complained about the convenience of modernity for centuries, but it can be quite fun to live in a modern way via a slightly more wandering route. It's less about throwing away modern life and more about the challenge of embracing -only- the good bits.

Don't stream, take the time to choose a Blu-Ray or CD to buy. Use cash next time at a grocery store. Use a Palm Pilot or a Newton for your calendar and an Alphasmart for your writing. Write down directions off of Google/Bing/OSM and sketch a little map.

All of these paths interface fine with the modern world, but there's great interest and satisfaction in small extra effort. What's boring is infinite, all-you-can-eat mediocrity. Make it even 5% more challenging and you'll 1) enjoy the journey more and 2) find what you value because now you're pulling rather than receiving a push.

I've also been considering adding C/C++ to my skillset out of a desire to have better foundational knowledge of legacy tech, and I can see a world where the pressure to learn the newest X results in a generation gap where no one can keep the lights on for existing systems.

Already rolling on this year's garden. :)

Been working on my French for a few years (~B1) and found Wesley's approach to be a really nice framework. I'm not using it 100%, but in general a combo of Duo, podcasts, Italki/tutoring, and a cahier/workbook works wonders.

Certainly enough to be able to wander into r/Quebec or r/France and follow conversations, collaborate with French coworkers (productively, but with errors), etc.

Side note: IMO the old Duolingo tree was better, particularly if you already knew -how- to learn languages (even if you've never retained one). If you put in the raw hours and know what you're looking for, it does stick.

New Duolingo...I think might work well for folks starting from the beginning. The changeover absolutely burned how I was using it, so while it was an important pillar early on, now it's much less so for me.

Using desktop+keyboard, reading it aloud, etc. is a must.

Combine that later with giving them access to what you use professionally. I graduated to Photoshop, Final Cut, etc. later via my dad.

Re. graphics/animation:

Depending on their age, an old copy of Kid Pix could be very entertaining. Good introduction to the concept of professional tools (Affinity, Photoshop, etc.) but a much more engaging UI (sound, skeuomorphism). Lets you add basic interactivity also.

What I haven't found a modern alternative to, but would recommend (somehow) would be Flash. It was a unique intersection between graphics, animation, and programming. I hacked together trading cards, games, stop-motion, websites, and animation with it and use principles I learned there every day.

Possibly the simplest equivalent today I've encountered would be Tumult Hype (note: Mac only :/). Nowhere near the same ecosystem, but it has a similar animation workflow (timeline, keyframing, nested animations, etc.). It lacks some of the additional artistic emphasis that made Flash so iconic and is really more of a straight web animation tool, but I suspect a kid could make more imaginative animations with it that I do. :)

- Static site with no framework beyond basic PUG/SCSS.

- Uses no JS at all.

- Actually pretty readable on a monochrome Palm Pilot too, as far as modern HTML goes.

---

My key post is my thought framework for ethical software design: https://calebk.com/articles/design-ethics

Have some fun ones on PalmOS UX and other experiments coming up, but unpublished for now. :)

I'm back to using mine (a monochrome model of the same vintage as show in the Archive screenshots) and, in 2022, I'm even writing apps for it. It's actually a ton of fun and ends up in my pocket far more than my phone.

Graffiti is still very intuitive. The display is a reasonable approximation of E Ink. Palm Desktop, hotsync, etc. all run fine on modern Windows machines, and I believe there are still viable Linux packages.

Turns out that TCP/IP is still TCP/IP and pretty much everything still "just works" provided you understand what it's trying to do (e.g. not be an iPhone). Mine automatically caches and syncs a few websites (including HN) as a sort of offline daily reading. You do need to appreciate the old Apple/iPod model where your computer is your hub and, for pre-wifi Palms, the network bridge.

They're just extremely focused little devices and excellent at what they do (calendar, notes, etc.). Treat it like it's a digital notepad, more in the vein of a pocket ReMarkable, and you might find it holds up better than you'd think.

They do, of course, add their own wrinkles, but at the time of adoption ostensibly the juice is worth the squeeze--at least for whatever real-world challenge a given team (or the broader dev culture) is facing at the time.

---

I'll still use pure HTML/CSS/JS for client projects, depending on the context. Usually for static sites or interactive UI/UX prototypes, both in freelance and day-job (agency, bigcorp) contexts. So far, folks are very happy with the outcomes, but I do vet the fit first. :)

In other contexts like enterprise/SaaS apps, Shopify builds, etc. I won't insist on no-JS or avoiding React/SPAs, as much as I'd secretly like to, but I will advocate for self-hosting and minimizing 3P JS dependencies where we're not necessarily gaining a huge increase in capability in exchange for dev convenience, etc.

It's a balance.

My homeschool upbringing included team sports, solo sports clubs, debate leagues, sleepovers, group field trips, scouting, community college, and various co-op models over the years.

Here's the difference--you're more likely to have mixed-age groups (particularly for elementary) and, critically, you're going to have much heavier adult involvement and guidance.

This gives a huge benefit: The social culture isn't defined by the kids. You have highly engaged adults acting as role models and vetted by the community. There's no critical mass of same-age peers defining the culture despite the best efforts of a handful of overworked administrators.

Additionally, there's usually a large amount of community collaboration and resource sharing. A key co-op for me in later years was essentially a group of local professionals who each taught their respective fields (writing, design, forensics, mathematics, etc.). Some were other parents with kids in the program, others were local experts. You still have a peer group spread between the classes--I had perhaps 20 in my immediate circle of a similar age, and a few hundred I met statewide during competitions--but by high school, the education essentially becomes student-led private tutoring with parental guidance, with a small-group shell and social extra-curriculars.

My answer to that question--which I know isn't the original but I think helps solve it--is that bridging the gap is, to a significant degree, the designer's job.

Note that I'm saying this as someone with a dev background but who formally took the UI/UX path, so there's definitely an "if all you have is a hammer" angle here. :)

My view: It is on the designer to have a reasonably strong technical understanding of what the application can and cannot do. IMO, design as a discipline is at least 50% engineering, because how it works under the hood has a dramatic impact on the end user experience.

---

Tips if you're on the design side:

- Ask technical questions, even if you don't really grasp the terminology yet. For example, where is this data coming from? Push the dev team deeper than broad answers ("the data lake"). Is this data cached uniquely for our application? How often? What's the response time? Does it come back in one big query or 15 little ones? Not understanding this results in annoyed devs asking you for loading states you didn't know you needed and will annoy you with a laggy app.

- Ask what libraries and frameworks the dev team is using. Read up on how they work. Walk through demos. If dev wants to purchase XYZ charting library, invest in understanding how it thinks so that you don't design something impossible. Conversely, once you have a good understanding, you're in a much better position to push back when it really matters. By making 90% of the app compatible with the dev team's tooling (which, remember, may have been forced upon them by politics elsewhere), you're buying goodwill for the really important, high-LOE custom bit that really should override dev reticence sometimes.

- For most projects, UI/UX is all about designing systems. The art is in the elegance of the system. The consistency, how it all meshes together, how easy it is to build upon and evolve. Express yourself in the beauty of that first, then add aesthetic exploration on top.

- And I can't emphasize this enough, if you can build your skillset to the point where you can build an average application in a rudimentary sense (i.e. it works, but isn't wired up or scalable), you will open so many doors and understand the dev team so much better.

---

Tips if you're on the dev side:

- Work to view your designer as your advocate and help them want to be it. Your designer should understand the implementation details 90% as well as you do. If they don't, help teach them. Show them how the framework thinks and why you chose it. If both sides come from years of cultural antagonism, this will require a lot of patience from both players.

- Remember that the designer is often reacting to feedback and external pressures just like the dev team is. They're trying to strike a balance between their best judgement (both as an individual and on behalf of users), the dev team's needs, the dreams of the business, and many other stakeholders who may or may not understand the process.

- Understand your designer's background. Even today some digital designers come from traditional design backgrounds and are learning to adapt to flexible viewports, etc. Note also that design tooling, especially in years past, could easily produce designs that exceeded the capabilities of HTML/CSS/et al. at the time (consider Photoshop CS2 vs IE6). It took deep technical knowledge and sometimes reversion of design best practices to reign the tooling in to something that a browser could efficiently support. I say this not to absolve responsibility, but drive empathy. :)

---

Also, shoutout to the answers by thomasqbrady [1] and apricot13 [2], who are capturing the "empathy" message I was trying to go for way better than I did. :)

[1] https://news.ycombinator.com/item?id=32153989 [2] https://news.ycombinator.com/item?id=32151110

I suspect I'm a fellow harbinger. I thought Apple was cool in the 90s and that Microsoft was on to something in the 00s-early 10s (including Win8/Phone), so I'm at least a solid 5+ years off (or, as a positive spin, simply much too early).

[1] https://boingboing.net/2019/12/03/harbringer-of-doom.html)

I also have a machine from 2007 in regular service, though in a secondary role (file server, etc.), but my daily driver isn't that much newer (2013, still a rust drive). Both machines have generated and continue to generate plenty of productivity and revenue.

I find that a little overbuilding in the right areas, like choosing a first-gen quad core in 2007 (often considered overkill on forums at the time), will greatly help the chances of you creating something that will last.

It's important not to hoard, but there's tremendous value in finding and maintaining quality. The advantage of old things is that you can point survivorship bias in your favor. Buying new, but very selectively with an eye towards 20-100y duty cycles (and maintaining them, like you're doing!) greatly helps in the same way.

Also, this doesn't directly address your question, but the interim solution I've used is to build a research habit with each successive purchase for the home.

With time, it gets a lot easier and more intuitive to track down vendors. Vendors is actually a key word--typically you're looking for one of a small number of authorized importers for a given brand. Often they'll be B2B focused, e.g. buying EU power tools or USA-made N95s from industrial supply companies.

This strategy has netted out a (simplified) distribution like this in my home:

* Home Appliances: German, French

* Food Storage: French (lunchboxes even!) or vintage US

* Whet Stones: Japanese

* Wooden Goods: Local, Canadian, or Eastern European

* Food: Local mills, garden, area farms; preserve seasonal foods

* Health & Beauty: Canadian

* Safety Gear: Canadian, US

* Garden: German, Italian, US; seeds from open-source genetics

You still have to be intentional, since plenty of foreign stores have global supply chains like the US does, so just because you're bringing it from Canada doesn't mean it's Canadian-origin, etc.

Also note: I'm absolutely cherry-picking what I listed. I still buy plenty of arbitrary things from big-box stores. In general, the research LOE scales with how important the purchase is to me, and you really need the research to become something of a hobby since you'll be spending hours on it. :)

I'm a UI/UX designer who was historically very invested in the Surface ecosystem during the early Win8/10 era, so this was a day-1 curiosity purchase for me.

As a physical object, I like it a lot. It's not _perfect_, but it has a great weight, the Dial has a satisfying resistance (like a 70s stereo knob), uses AAAs, and the haptic feedback is solid for a digitally-triggered vibrating motor (vs a literal ratchet).

What I find, however, is that it's a superior consumption tool vs creation tool. It's at its best when being used as a single-function knob. Great for sitting at a desk while reading a whitepaper, or perhaps controlling volume while listening to music. Day to day I use a mouse with a stepped-wheel, but the smooth scroll on the Dial makes it my preferred way to handle longform content. Keeps a long article flowing.

However, it has not become an indispensable part of my workflow. That may just be me. I need to pivot between Windows/macOS/Linux over the course of a day, so a lot of its proprietary-tech promise is wasted and I've built fewer habits. I'm also not sure offhand how good the integration is with design tools after the initial fanfare around Adobe, Surface Studio, etc.

Other tricky part: It's bluetooth. Once it's awake and in-use, that's...acceptable, if you aren't actively looking for tiny bits of input lag. But if you need it on-demand (sudden noise from the speakers, etc.) and you haven't used it in a while, it may be a couple seconds before it's responsive to that first input.

Still, it _is_ intriguing enough to me that years-on, it's still on my desk and is one of the only bluetooth devices I own, much less tolerate using. I think it's at it's best when it's a context-sensitive linear actuator with some light multifunction capability vs a new paradigm.