Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

It was electrifying. Understand that by 1984 there were millions of Americans using computers with a command line interface. While they could all do game graphics, you always started out in text mode and had to learn incantations that are familiar to many users of this site but which are no longer a part of most users’ daily life: dir, cd, del, etc.

Seeing how dramatically different a computer experience could be was like opening a door to an alternate universe for people. The day after the Super Bowl in 1984 when their famous big Brother commercial ran, my girlfriend’s computer-illiterate father announced to us “I know how to use a computer now” and of course I knew exactly why.



I would urge developers to also take a look at the early "Inside Macintosh" series, which tried to explain Apple's Human Interface Guidelines to programmers. Take a particular look at Vol1-Chapter 2 [1] to see how hard Apple worked to explain how to design consistent and usable apps. All of this advice ("avoid modals", "group commands in menus") seems trivial to us now: that's how GUIs have worked for most of our lives. But prior to Mac most apps looked like vim. These ideas had to be designed and then taught, and Apple spent a huge amount of effort on those books.

[1] https://vintageapple.org/inside_o/pdf/Inside_Macintosh_Volum...


Also worth reading is Tog on Interface by an early Apple employee who was Apple's Human Interface Evangelist in that period. One particularly interesting essay goes into the issues associated with the way that developers are used to dealing with abstract models in a way that many users aren't. (He bases his argument in part of Meyers Briggs which is astrology to some degree--but the basic point stands.)


Yes, the shift of consumer computers from command-line only to graphical interfaces would have been bigger than the Wizard of oz moment where the movie transitions from monochrome to colour.

I contrast this to Meta VR's comically atrocious demos and wonder what happened.


> I contrast this to Meta VR's comically atrocious demos and wonder what happened.

How so? They’re showing the best with the limits of current mobile technology that can maintain 75Hz. Cloud VR isn’t here yet, because 5G isn’t here yet. In 5 years, some of those limits will be gone, 10 years even more, but it would be silly if they waited 10 years to start.

I think part of the problem is that you can’t take a picture of VR and show it to someone. It doesn’t translate. Things that look ugly in 2D look much better in 3D. This is a huge problem with VR game trailers.

For example, the new avatars looked much better, “in person”, than with 2d screenshots. 3d is a very real part of our perception that I think many things can benefit from, especially data visualization.


There is a aphorism that goes like "good technology is indistuishable from magic".

What gain is there in publicizing these half assed updates that don't inspire any consumer confidence?Except to maybe vested parties like advertisers and, shudder to think, metaverse real estate agents.


I’m sorry, but no technology has started in its final state. Metas communication has been very very clear that we’re in the infancy of it all. See the latest keynote for multiple examples.


Steve Jobs had at least enough product sense to avoid releasing the iPhone and iPod for years while they were in early development.

Meta has none of this.

Apple succeeded (and succeeds still) because of the company’s culture of obsessiveness. The original motto of Facebook was “move fast and break things” which might have worked well for an evolving social media darling but it’s not surprising that they’re failing constantly at shipping real world products.

John Carmack (now a Meta employee) openly complains that he’s not happy with their expensive unaffordable product that has terrible performance for users. Taking this analogy further, in this case Meta is like IBM with a research facility developing expensive GUI prototypes, just waiting for an enterprising startup to rehash their ideas into something affordable, enjoyable, and usable for most people.


> surprising that they’re failing constantly at shipping real world products.

By what metric?

Quest 2 sold better than the Xbox [1], more than 10 million units [2]. It’s the number 1 PCVR headset [3], almost 2x usage of Valve Index.

1. https://www.androidcentral.com/gaming/virtual-reality/quest-...

2. https://www.theverge.com/2021/11/16/22785469/meta-oculus-que...

3. https://uploadvr.com/may-2021-steam-hardware-survey/


Because Meta is just not the player to innovate VR. It has existed for a very long time, and Meta hasn’t been able to go any further than games that already exist long ago.


> Meta hasn’t been able to go any further than games that already exist long ago.

The Quest Pro is, literally, the “further”, outside of games. Check out the keynote! As was stated in that keynote, there's still a long way to go.

I don't think this perspective that meta is responsible for all the software makes sense. They're building a platform/framework for everyone to innovate, not just themselves.

As someone who codes in VR a few times a week (B&W passthrough version of this [1]), I think it's the future of display tech.

1. https://twitter.com/MKBHD/status/1580917421757587456?s=20&t=...


> bigger than the Wizard of oz moment where the movie transitions from monochrome to colour

I have never heard anyone put it better than that.


Or what about `himem`? I remember I had to do that command first. Otherwise, something in railroad tycoon or Civ would not work. I don’t recall exactly what it was, the pointer, high res colour graphics, or sound or maybe the combination of the above. I just knew I had to type that first. Didn’t have a clue at the time what it was.


Come dos 6 there were menu options in config.sys you could use to load different parts of your hardware depending on what you wanted, they also could do different things in autoexec.bat too. Before that you could just have different boot floppies.

My memory had himem.sys as a config.sys option though, with various numbers you could pass to it. EMM386 was another one too.

It was tricky to work out what you could do - a lot of trial and error, this was in the pre-internet time (at least for the typical home user), so things tended to come from hints in magazines.


Wow, I remember this! As a kid, I remember taking my computer to an IT shop asking how to run a copy of Ultima VI on my Pentium II MMX PC. The tech there had it for a week, and they figured it out by setting up autoexec.bat so that I had to allow/disallow some processes from booting one by one.

Apparently one of those tricks was reducing the amount of available memory, or something like that. That was the hack that got U6 to boot and be playable at a normal speed.

This would have been in 1998 or so, so my memories of the exact fix are pretty faint.


To be fair, the Mac alternative at the time was "Don't do that." DOS and the PC (and add-ons like expanded memory) provided a bunch of ways for sophisticated users to do things that weren't quite possible with stock configurations. (Basically there was memory between 640K and 1MB that could be used in various ways but it required the right incantations.)

My general recollection from being a DOS power user (and developer) and a very sometime Mac user in that era was that Macs were less likely to be "problematic" but when something did go wrong, you had far fewer tools and observability to work around the problem.


The Mac from that era had a built-in hardware debugger. Literally pressing the button on the front of the case dropped you straight into Macsbugs. Something I used extensively to crack software copy protection.

If you knew Macsbugs, ResEdit and Codewarrior you had complete control of your software and hardware.


>>Literally pressing the button on the front of the case dropped you straight into Macsbugs.

Or better yet, TMON[1]! What an amazing debugger. I spent many hours in there, trying to figure out why the 64K ROM was stepping all over registers that were supposed to be protected by particular ROM traps. (to be fair, there were not too many of these, and they were all eventually patched by system updates)

[1] https://www.macintoshrepository.org/1400-tmon


That period didn’t last very long, though — by 1986, the Mac Plus had a megabyte of memory standard, and still a flat address space — no HIMEM required.

On the second point, generally the hardware was reliable, and Mac users had tools available to diagnose software issues. There just wasn’t any printing stuff to a console.


> To be fair, the Mac alternative at the time was "Don't do that."

Well, no. The Mac alternative to DOS TSRs that loaded in High Memory would be Desk Accessories.

>Introduced in 1984 as part of the operating system for the Apple Macintosh computer, a Desk Accessory (DA) was a piece of software written as a device driver, conforming to a particular programming model. The purpose of this model was to permit very small helper-type applications to be run concurrently with any other application on the system. This provided a small degree of multitasking on a system that initially did not have any other multitasking ability.

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


> It was electrifying.

The only time I've seen a demo of new tech that gave me the same feeling of inevitability came from Jeff Han's multitouch demo.

https://www.youtube.com/watch?v=ac0E6deG4AU


Masterful. It does feel much the same way.




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

Search: