Hacker News new | past | comments | ask | show | jobs | submit login
Apple IIe Design Guidelines (1982) [pdf] (apple2scans.net)
142 points by Aqua_Geek on Aug 22, 2017 | hide | past | favorite | 34 comments



This reminds me of some words of advice I noticed in an even older manual for the Apple II floppy disk drive:

"To load a program named AGATHA, use the command LOAD AGATHA and the program of that name, if there is one in the catalog, will be loaded. To test if AGATHA is loaded, see if it can walk along a straight line."

http://imgur.com/wWtR6wp


The early Apple ][ docs were quite lighthearted. From the 'Applesoft Tutorial':

http://i.imgur.com/LfVSFK2.png


Someone wrote (and then apparently deleted) an interesting comment pointing out this was originally written by Jeff Raskin in the 'Apple II Basic Programming Manual'.

The screenshots are from a later version called 'The Applesoft Tutorial', revised by Caryl Richardson. That version has no author credits.


The very embodiment of the spirit of computing in the 70s/80s, which is sadly missing across a large swath of computing today.


This took me a couple re-reads to get. Very nice.


Sigh. I really wish Apple and Microsoft would re-acquaint themselves with these ancient Apple user interface guidelines/recommendations!

IMHO Microsoft has gone from the best UI to a horrible UI. No way of visually discerning what is a button or other GUI component and what isn't is not a improvement! The revolt due to their absurd VS GUI a while back is a great example, but it's the subtle UI changes in their current offerings that are most frustrating.

I switched to linux a while ago, and it has a long way to go ... but its an upward curve vs. Apple/MS's downward spiral when it comes to UI.


> but its an upward curve vs. Apple/MS's downward spiral when it comes to UI

It's upward because it's trying to catch up with Windows and macOS...

As much as I would love to love Linux, besides elementary OS the trend is still to ignore looks and concentrate on code. Some apps are so poorly thought out in terms of UI that they're almost impossible to use.


There's bad, and then there's GIMP. GIMP's general UI thought is, "we thought you might need this button... sometime... maybe this week... so here it is".


Big time.


I don't see it. The problem with the large open source community projects recently (Unity, Firefox, etc) is that they go for flash instead of substance. This isn't just a bunch of bedroom hackers anymore, there's plenty of invasion of the designers making dumb decisions, too. But still, I prefer Linux on the desktop these days to the insanity of the other 2 major options.


> Some apps are so poorly thought out in terms of UI that they're almost impossible to use.

Considering most of those apps probably are open source why don't you help out and improve them?


Many reasons.

While I can tell that something is a pain to use, I'm not a designer, and I don't know how to fix it. Kind of when your car makes a noise or breaks down and you're not a mechanic.

I can't technically because I don't program for the desktop, and I don't have the time nor energy, and prefer/have to pay people to do it for me.

I have to tell you, I love how whenever someone criticizes Linux there's a comment saying "it's open source, fix it yourself". I think this is exactly the problem and attitude that plagues most Linux distros.

Criticizing is helping.


That's fine for a competent developer with a lot of time on their hands, but do you consider this to be a practical approach for the average Linux user?


Average users don't use Linux. Considering that you're getting thousands of man months for free by using the kernel and open source tools I would imagine you pitching in to help with a little bit of your time.


> Average users don't use Linux

You'd be surprised. My sister uses Ubuntu (no idea how she got the idea), and she's in a totally different field.

> Considering that you're getting thousands of man months for free by using the kernel and open source tools I would imagine you pitching in to help with a little bit of your time.

People release open source projects for different reasons.

I don't think it should be required physically or ethically to have to pitch in to help, even if one was capable of.

Fixing other people's code in a disk partitioner or text editor is not what I'm passionate about nor what I want to spend time on. Then, I'd rather pay (as I do) for Sublime Text and start working on things that I care about already (on macOS—which I definitely pay for).


What about sysadmins, web developers... ? This is what I mean by average Linux user. These people aren't coding native apps all day.

The class of people qualified to contribute to open source Linux utilities is a subset of Linux users.


I tried to stick to (old) Apple interface guidelines for a long time. Eventually I realised, for instance, that only tiny numbers of people need to be taught how to use a mouse.


Interesting story is how the Apple III is needlessly turned into a reliability (and commercial) disaster because mr. Steve "genius" Jobs stupidly insisted that the machine shall have no fans.

So the thing -dozens of ICs inside- overheated so much to the point of failure. This was already warned by their (capable, well respected) designer Wendell Sanders, but Jobs, being Jobs, wanted things his way.

Full story must be in folklore.org.


That anecdote on user testing is a real screamer (p16). Who would have thunk the most difficult UX issue would be asking users if they're using a color monitor.


Back in the days of the Apple IIe color monitors were extremely expensive. The first one I bought (A Sony KX14CP1) cost me almost as much as the computer it was connected to. Before then I used a small monochrome monitor (composite video).

Color really wasn't something you could assume people had. late 80's is roughly when color started to be 'normal' (mostly driven by the IBM PC shipping with CGA since launch in '91) and people looked at you strangely if you still had monochrome.

And even then, if you wanted high resolution chances were that you'd be looking at a monochrome display.


Plenty of us got by with color, but it was via an RF modulator to a little TV set.


Yes, hence the 'monitor' in italics, color monitors were expensive, color TVs were cheap (heck, you could find them at the garbage). Hacking color TVs to give them RGB inputs was another avenue, as was bypassing the modulator/demodulator step to push composite video straight into the TV at the right spot to get a crisper image.


When I was a kid, I found out I could just send the composite output to the RCA input on the back of my Betamax... and then RF out to channel 3/4 on my color TV. I didn't even need to save the 13 bucks for the RF modulator from Nibble.


And even then, if you wanted high resolution chances were that you'd be looking at a monochrome display.

Yeah, it wasn't so much that the color monitors were expensive, but that they were terrible. I always kept my Monitor /// even when co-workers had color displays.

The RGB monitors on the IIGS were great, though.


I had one of those green monochrome Apple monitors, complete with inset CRT that swiveled up or down a few degrees within the monitor case, driven by my 80-column-card-wielding ][e. I remember going to a friend's house to admire the exoticism of the "amberglow" display on his machine. Amber!


That's how I played King's Quest at home (or tried to... it was a little hard at that age). And some game with jousting and darts (may have been part of King's Quest).


It was called Chivalry, and it was not part of King's Quest. It was like a board game and you had to roll the die or spin the wheel to advance a certain number of spaces. Each space you could land on had a different minigame.


> (mostly driven by the IBM PC shipping with CGA since launch in '91)

The PC was launched in 81, and the default display was monochrome text; 91 might have been the PS/2 with MCGA.

Or maybe you meant to refer to the PCjr, which was bundled with a color display (better than CGA, IIRC) at launch. That was, IIRC, 1983.


That was a typo, '91 should have been '81, and even if the default display was monochrome text CGA really was available from launch.

https://en.wikipedia.org/wiki/Color_Graphics_Adapter

Seems to confirm it was available from the launch date and I distinctly remember a job for a company in Edam that had an early PC which had color graphics as well as one at a bank in Amsterdam that also did color (at very low resolution, but definitely color).

By '91 we were well into 486's and high res color (but not using IBM cards, but VGA wonder and the various Tseng cards were doing just fine).


It's an amusing anecdote, but it's impossible to argue that the process they went through resulted in a better product.

I don't want to use software that's designed for people who are too oblivious to know if they're using a color display, or designed by programmers who try everything besides asking the simple question, "Are you using a color display? Y/N"

Also, as soon as participants start screwing with the process by lying to the program and/or the investigators, there is no longer any great likelihood that ordinary users will benefit.

The correct solution is, of course, to design the program to look good on both color and monochrome displays, like almost everyone who ever developed games for the Apple II had to do. It was difficult to pull this off due to the interaction of the display hardware with archaic TV color standards, but it was part of the job.


"a brief, 20 minute pause." The age of zen computing!


My favourite bit of design advice is for when a program is about to delete a lot of user data.

The program should require cognizant confirmation:

  Are you sure you want to destroy 5 days' work? Type DESTROY 5 DAYS' WORK to confirm.


Thank you for scanning and posting this. I have a copy kicking about and keep meaning to share.


I love that it's pw protected. :/ Simply Beautiful. Boom.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: