Fort Forecast »

Talk: Civilization

This is the talk page for discussing the FortForecast.Civ article.

References / relevant reading material

General commentary

StructureOfWikis (archived) on CommunityWiki

Imposing structure on unstructured content

GlobalContentStructuringMethods (archived) on CommunityWiki

Ways to structure content

SeedPosting (archived) on MeatballWiki

This is re: "start with value" (and related topics)

IndexingScheme (archived) on MeatballWiki

Possible ways to index (and provide navigation of) content

Other ideas/projects; feature ideas

AmiCog (archived) by Douglas Reay

See also Discussion of AmiCog (archived)

ViewPoint (archived) and ViewPoint-Comments (archived) on MeatballWiki

FrontLawn (archived) on MeatballWiki

Providing users with a personal space on the wiki to increase sense of ownership/belonging

Soft links (archived), a unique feature of Everything2

Links between pages, generated by automated observation of users’ navigation/movement patterns within the site

Wikipedia feature suggestions (archived) on gwern's user page

A gold mine of good ideas!

UX design / features / etc.

Views

The idea of “different views on the same data” is crucial. It’s ubiquitous in desktop applications—so much so that we forget about it—the proverbial water to the proverbial fish. It’s not nearly as common in modern web apps as it should be. Before discussing how it applies to Civilization, here are some examples, because it’s important to fully grasp just how basic and fundamental this concept is.

Example one: Finder windows

Note for non-Mac-users: the Finder (archived) is the graphical file manager on the Mac OS. (It also does other things, but that's the part of its role that we're concerned with here.)

In all of the examples in this section, the data is the same: “what files are in this folder?” Let’s look at some of the possible views onto this kind of data.

Figures 1–4 show the same folder in each of the four different available view modes: list, icon, column, and cover flow.

Let's play a game of “spot the difference” between Fig. 1 (list view) and Fig. 2 (icon view). Here we're not concerned with visual differences, but with UX differences. Here's a partial list:

(1) List view shows more metadata. (Here we see modification date, size, type; view options allow us to show more/other columns, like date added, version, tags, etc.)

Does the icon view show no metadata at all? Nope, it shows at least one piece of metadata: the file type—via the file icon. (This is an example of multiplexing; the icon has to be something—to provide a visual representation of a file, and to provide a click target—so why not multiplex file-type data into it?)

Of course, the icon is also visible in list view (but smaller); this means that in list view, file type is conveyed twice (if the “Kind” column is enabled). This is an example of redundancy in UI design, and of good use of sensory (in this case, visual) bandwidth (of which there is quite a lot!). Notice that this redundancy affords the UI a degree of freedom it would not otherwise have: the “Kind” column can be turned off (making room for other data columns, or allowing the window to be made smaller, to make room for other stuff on the screen) with minimal loss of information throughput for the UI.

But wait! What about the file name? There's metadata lurking there, too—the file type again, encoded this time in the file extension. Redundancy again; the file type is therefore displayed in three ways in list view (“Kind” column, icon, file extension) and in two ways in icon view (icon, file extension).

All of this gives the UI several degrees of freedom. How is this freedom spent? In at least two ways:

1. To allow for one or more of the channels through which file type information is communicated to be disabled or repurposed in certain circumstances, with minimal loss of information. (An example of a disabled channel: the “Kind” column is absent in icon view, but file type information is still visible. For an example of a repurposed channel, see the notes on Figures 5–9, below.)
2. To compensate for unreliability of some or all of the channels through which file type information is communicated. Sources of unreliability include:
   • The Finder may not recognize some obscure file types (the “Kind” column would then display no useful information); the file extension may be the only source of file type data in this case
   • The file extension may be missing (but Finder attributes may be set, thus allowing an appropriate icon to be shown and an appropriate value to be displayed in the “Kind” column)
   • The file icon channel may be repurposed (Again, see the notes on Figures 5–9, below, for an example)

(2) List view allows sorting. (Click on a column name to sort by that column's value; click again to reverse the sort order.)

… or is this really a difference? Actually, files can be sorted in icon view as well (there is both a “one-time sort” option and a “keep sorted by…” option). This is not obvious, because the UI for sorting in icon view is not discoverable by mere physical inspection, whereas in list view the column headers are visible, the sort order indicator is visible (the triangle, pointing up or down), and the “click column header to sort tabular data by that column's value” is a well-known idiom. (In icon view, sorting is done via a menu—either from the menubar, or from the context menu, or from a menu in the window toolbar.)

There is, however, a more subtle difference: in icon view it is not possible to sort in reverse order. Why not? The only reason is that Apple was unable (or unmotivated) to design a good UI for reversing sort order in icon view.

General lessons:

• The same (or analogous) forms of interaction with the data may be implemented via different UI designs in one view vs. another view.
• If the UX for a particular interaction in one view is obvious, don't assume that in other views it's impossible to design and implement.
• However, not all interactions that are possible in one view need to be (or can be) available in all views. (It makes little sense to provide “one-time sort” functionality in list view.)

Design principles:

1. In each view, provide as many interactions as is reasonable, no more and no less. (Provide more and you clutter and complicate the UI; provide fewer and some or all of the views will be too capability-poor to be useful.)
2. Strive to have each view provide as complete a set of interactions with the data as possible,.
3. To reconcile the tension between the above two design principles, remember that it's better to provide a capability and hide it away behind a non-obvious or non-trivial-to-discover UI than not to provide it at all. This way, it will be available for power users but will not trouble less experienced users. (Of course, this is not an excuse to hide capabilities behind non-obvious UIs when there's a good reason, and a good way, to provide an easily-discoverable UI for them.)
4. At the same time, look for ways to exploit the unique properties of each view to provide additional interactions that would impossible or nonsensical in other views.
5. The more ways the user can interact with the data, the better.

(3) Icon view allows arbitrary grouping and arrangement; I can position the files in the window wherever I like (example 1, example 2, example 3, example 4, example 5).

(Unless a “keep sorted by…” option is enabled.)

Some file managers don't have this feature; the Finder does. The lesson:

Do not carry over UX/interaction limitations necessitated by one view, to another view where they are not necessary.

Arbitrary grouping and arrangement makes little sense in list view. In icon view, there's no reason not to permit it—except, of course, that allowing the user to set, and then tracking, arbitrary icon positions, takes work! Does it offer a benefit? Find out! Ask users, survey other implementations, etc. In general, users resent limitations on their freedom, and appreciate the lack of them.

(4) What aspect(s) of the data may be easily gleaned via visual inspection differs from one view to another.

Different views (usually) look different. It's easy to forget this, but it's crucial. Here (in the “Finder list view vs. Finder icon view” example) this manifests in a couple of ways:

1. In list view, it's easier to pick out files which differ from the others in any displayed metadata value (modification date, file name, etc.). This is true not only due to the sort feature, but also because humans find it easy to scan down a list of text items (which are horizontally aligned) and notice ones which stand out.
2. In icon view, the "file icon" data channel is wider (because the icon is displayed at a larger size); more data is coming through this channel. This makes it easier to distinguish icons, but also allows this channel to be used for other purposes (see notes on Figures 5–9, below).

General lessons:

For humans, the visual channel is a high-bandwidth one. Use it. Some ways to optimize UI visual bandwidth:

• Multiplex meaning.
• Allow the repurposing of high-bandwidth components.
• Remove obstacles to visual apprehension of patterns (minimize "non-data ink", etc.).
• Assist the brain's pattern-recognition abilities by using alignment, contrast, repetition, and proximity cues.

---

The same folder as in Fig. 1 and Fig. 2, but now in column view (Fig. 3) and cover flow view (Fig. 4):

---

Example two: Microsoft Word document windows

Example three: structured data

1. A .csv file, displayed as plain text
2. The same .csv file, opened in Excel
3. An HTML file, containing the same data, plus markup such that the data will be displayed in tabular form, displayed as plain text
4. The same HTML file, rendered in a browser

Robustness

• Open source
• Open content
• Backups

All of these are critical for robustness.

What happens if the guy who runs Pinboard gets hit by a bus?

The bus is likely to be fine. They don't go very fast and are designed with passenger safety in mind.

—from the Pinboard FAQ (archived)

Maciej jokes, but actually, that would suck, right? Pinboard is just a bookmarking site, yet still, if tomorrow it went offline forever—that would suck. Like, a lot.

Is a Civilization-based project (like, say, FortForecast) at least as important, valuable, irreplaceable, etc., as Pinboard? If it is, then we should give some real thought to what happens if the person or people running it get hit by a bus. (Or if they have a mental breakdown and take the server down. Or if they get arrested. Or, or, or...)

If you're trying to make something for the ages, there are several ways to fail. You could fail to produce anything that's worth preserving. But you could also fail to preserve something that is worth preserving.

The first problem's hard, and the rest of the site talks about it. This is about the second problem.

Open source

This is already a project goal, but worth repeating. If we do something wrong, someone forks the code and does it better. If we die, someone grabs the code and carries on. If the inexorable march of progress passes our creation by, someone updates it. At worst, it serves as a seed for a better incarnation.

(This is all in addition to all the other benefits of FOSS.)

Open content

This one's less talked about. Source being open doesn't do anything for the content of a Civilization-based project, which—to put it conservatively—is at least as important as the code.

What does "open content" mean?

It means: suppose I have a Civilization instance, and you have a Civilization instance. We have no connection, we're just two people with two servers who are each running the software. You have a lot of content on your site; I have nothing (I've just deployed a brand-new instance).

1. How hard is it for me to grab all your content, dump it into my Civilization instance, and have a working mirror of your site?
2. If your site goes offline tomorrow, is your content now all immediately inaccessible?

Without open content, a Civilization-based project isn't robust. The bus threat still looms large.

Notes

Concerning (a): Would anyone want to do this? Maybe. But reasons aside, if it's hard or impossible to do, then there's a smaller chance that the content will survive the death of project's current host.

Concerning (b): Consider the analogy with an open source project. Suppose I release the source code to my product under a FOSS license. I put the source up on my personal site. Tomorrow my server explodes and I die. No one else has the code (or if they do, they're not telling). Technically, the product is still open-source.

Does that help you, the hypothetical developer who wants to hack at it? Nope. This is why github and sourceforge and so on exist. The same considerations apply if we commit to the idea of "open content".

Case studies

• Wikipedia
• Less Wrong

Obstacles

• Copyright
• Dynamic content generation (where the generation process depends on content which can't be open, or local configuration, etc.)
• Content itself which is inextricably tied to idiosyncracies of platform/host/etc. configuration, or uncommon technical capabilities
• Dependency on external services
• Operational costs (such as storage)

Content which can't be open

• User data
• Private content (conversations taking place via a "private message" feature, non-public forums, etc.)
• Content which isn't hosted by the project itself, but which is somehow a part of project content

Backups

This one's obvious: if something happens to the project's technical base, but the people running it are still hale, hearty, and present, a return to operation should be quick.

This aspect of robustness needn't be limited to just the usual backup strategies, though. Supplementary approaches include:

• Zip everything up and throw it into torrent-space
• Put it in a public github repo
• Mirror content archives on publicly accessible sites

… etc.

If nothing short of literal global themonuclear war can take down the project—then you're sufficiently backed up.

TODO: Improvements to this page

<Obormot> Rereading http://wiki.fortforecast.com/Civ/Civ (archived) - some observations:

<Obormot> Under "Rationale", you say a bunch of things which don't really describe the rationale very well or completely

<Obormot> They're important, and need to be on this page, but they don't actually answer the implicit question of that section, i.e. "why this thing, at all"

<Obormot> "Civilization is meant to be a framework for building sane online institutions. This means having high quality indexing of documents, powerful search to go with the index, document storage, space for discussion, and reasonable means to direct people towards the completion of goals. The indexing is paramount, what separates the university from Reddit is that the former puts incredible work into indexing and quality rather than ephemera."

<Obormot> The missing link in the chain of reasoning here is, what does building sane online institutions have to do with any of this stuff you list

<Obormot> "X. This means y and z" but why does it mean that

<Obormot> You know why and I know why, but no one reading this knows why

<namespace> Okay.

<Obormot> So that needs fixed imo

<namespace> Sure.

<Obormot> "In the Civilization taxonomy each 'thread' should produce an artifact of some kind." also a missing link - how'd we get to "threads"? This one's easier to solve, probably, just add something to the effect of, our hypothetical sane online institutions discuss things in a forum-like environment/system

<Obormot> (I'm sure you know this, but just to put it out there: I'm harping on these 'missing steps' because making the claims explicit makes it easier for us, and others, to challenge them, which is what we want)

• HomePage
• WikiSandbox

• Support OborWiki!

• Site Settings

---