I think, while icon + label is good for things like UI buttons, this is not that great for tables. There are a few reasons for this:
- icons really work only as a small set (e.g. checkmarks versus crosses or similar) – so the only useful application is also in a context which is already highly selective and with low ambiguity. (Familiarity helps and should be a major concern.)
- icons are useful for scanning for rows with a given property – however, to scan icon + label we must not only scan horizontally as well as vertically, but have also to scan items with varying column alignment, which isn't favorable for a vertical scan, either.
So, if it is a case for icons, say, each row has a state out of a set of three, there shouldn't be need for an accompanying text label (this can be learned from a tooltip or a legend), which is also apt to destroys most of the advantages of having icons in the first place. Having both just introduces a mode change, which isn't helpful for scanning, either. If you must have both, put them in separate (adjacent) columns. (In this context, we may note that tables are really about reducing redundancy, though.)
Moreover, to be meaningful in tables (or menus – yes, I'm speaking of recent macOS), icons should only be used to represent state or to represent actions that modify state. There are, of course, exceptions to this, but this may be still a viable starting point…
I'm a confessing user of em-dashes (or en-dashes in fonts that feature overly accentuated em-dashes). It's actually kind of hard to not use them, if you've ever worked with typography and know your dashes and hyphenations. —[sic!] Also, those dashes are conveniently accessible on a Mac keyboard. There may be some Win/PC bias in the em-dash giveaway theory.
A few writer friends even had a coffee mug with the alt+number combination for em-dash in Windows, given by a content marketing company. It was already very widespread in writing circles years ago. Developers keep forgetting they're in a massively isolated bubble.
The site covers mostly retro- and classic computing. (Strictly no AI generated content.) Here in convenient format:
(
:name "Norbert Landsteiner"
:site "https://masswerk.at/"
:blog "https://masswerk.at/nowgobang/"
:feed "https://masswerk.at/nowgobang/feed.xml" //covers blog only
:about "https://masswerk.at/info/" //legal info
:hnuid "masswerk"
:bio "web developer and designer, site content is mostly retro- and classic computing."
)
Your Pet 2001 emulator's pretty cool, and seems much more capable and user friendly than a lot of the downloadable alternatives.
Actually a bit of an issue, its so capable, I actually have difficulty justifying a downloadable alternative, even though I'd prefer to have a local copy due to the untrustworthiness of web apps over time.
Thank you! I can see that this may a bit of an issue. However, this being a simple webpage is what allows to quickly tinker with this and push a quick update, which is also how much of this has kept growing.
The choice of AppleSoft BASIC for a recreation seems to be somewhat odd and deliberate, and doesn't represent the typical limitations of the time (AppleSoft BASIC does floating point math!): in August 1975, the MOS 6502 hadn't even been announced and the Apple ][ wasn't yet a dream. Even Microsoft 4K BASIC for the Altair hadn't been introduced, yet (this was to happen only later in October.) Meaning, none of the basic technology of choice would have been available.
Something along the lines of Intel 8080 assembly may have been more appropriate, given that the target platform would have probably been a coin-op machine. (Given that "Gun Fight", the first arcade video game utilising a microprocessor, wasn't yet released, even this would have been an ambitious choice. Atari doing research for something that required an ALU may be even more interesting than the involvement of the young Steve Jobs.)
PS: This is just to give some truth to "this is where the hackersnews jerks will say this is an ad". ;-)
Yeah... it's a bit unclear to me what hardware this was even supposed to run on? The home and arcade video games Atari was producing at the time (Pong and later Breakout) were based on discrete logic chips, so weren't "programmable" in any modern sense of the word. As you wrote, the 6502 was only introduced later in 1975, and designs using it came even later.
Notably, Dave Nutting Associates (Bushnell's former employer, who also distributed Computer Space) had played around with an Intel 4004 in 1974 and then demonstrated (to Bally) a CPU based system with a frame buffer in September, which evolved into the Intel 8080-based board that ran Midway's Gun Fight. Atari would have probably been aware of this (Nutting Associates had filed a patent.) So, something along the lines of Intel 4004 or 8080 machine code, maybe M6800.
Curious detail: the button/widget icons of the browser chrome are composed of multi-layered box-shadows (i.e. one box-shadow definition per pixel or line, concatenated to a sting) of a `:before` pseudo element. (I don't think that I've seen anything alike before.)
For example, when a process implies a conversion according to the contract/convention, but we know that this conversion may be not the expected result and the input may be based on semantic misconceptions. E.g., assemblers and contextually truncated values for operands: while there's no issue with the grammar or syntax or intrinsic semantics, a higher level misconception may be involved (e.g., regarding address modes), resulting in a correct but still non-functional output. So, "In this individual case, there may be or may be not an issue. Please, check. (Not resolvable on our end.)"
(Disclaimer: I know that this is a very much classic computing and that this is now mostly moved to the global TOS, but still, it's the classic example for a warning.)
- icons really work only as a small set (e.g. checkmarks versus crosses or similar) – so the only useful application is also in a context which is already highly selective and with low ambiguity. (Familiarity helps and should be a major concern.)
- icons are useful for scanning for rows with a given property – however, to scan icon + label we must not only scan horizontally as well as vertically, but have also to scan items with varying column alignment, which isn't favorable for a vertical scan, either.
So, if it is a case for icons, say, each row has a state out of a set of three, there shouldn't be need for an accompanying text label (this can be learned from a tooltip or a legend), which is also apt to destroys most of the advantages of having icons in the first place. Having both just introduces a mode change, which isn't helpful for scanning, either. If you must have both, put them in separate (adjacent) columns. (In this context, we may note that tables are really about reducing redundancy, though.)
Moreover, to be meaningful in tables (or menus – yes, I'm speaking of recent macOS), icons should only be used to represent state or to represent actions that modify state. There are, of course, exceptions to this, but this may be still a viable starting point…
reply