trogdoro

Braille has many of the same properties, and it could be worthwhile to train yourself to read it visually. If you went down that path, though, I think you'd get to a point where you'd say: hmm, if I'm going to start over I might as well make the letters one column of dots, so the words are roughly square-ish and can form more visually distinct shapes. The shape of Braille words wouldn't be much of an improvement over Latin - unnecessarily long and skinny. Which is probably a good fit for a finger but less optimal for an eye. And then there's that unnecessary sixth dot.

As to the originality, most computer science students have looked at a binary versions of ascii charts at one time or another. Turning them sideways and making a font out of it isn't discovering relativity. On the other hand, even Braille had its percursors (see your Wikipedia link), and Braille users don't reject it on that account, do they?

> Silicon Valley

You're assuming I'm from Silicon Valley. I am here now, but was actually in Ohio when I came up with Dotsies :)

The terminal is tricky, due to the monospace aspect. It degrades readability when the spaces between the words are as skinny as the letters, but that's what a requirement of a monospace font. One (though not perfect) workaround is to make both the spaces and the letters a little fatter. Also making the numbers readable is a challenge with monospace. I've made numbers that are more adapted to the terminal, but they could use some improvement.

I tried that, as well as with color variations. The problem that arises is when you view them at small or even medium font sizes, a black dot next to a red or gray dot just looks like a blurry black dot.

I like your mapping just about as well as the Dotsies mapping. Slightly more speckled vs angular. I wish others who are finding fault with the mapping would go down this path as well. I think they would quickly realize that one mapping is (generally speaking) about as good as another, so you might as well pick one with a good order. That's why I created that page.

> But then chinese websites have very small fonts as well

Right you are.

It took me a while to be able to shrink it down. You have to start large and gradually shrink it down.

> If I could watch someone reading fluently in dotsies

Any time.

I added several characters to the Dotsies font for other languages in response to requests. They have accents above the dots.

> It doesn't really make sense to optimize for screen space like this. However, the teaching style along with a symbol alphabet that IS trying to solve for better legibility ...

Optimizing for legibility as opposed to screen space is a distinction that isn't very meaningful in practice. Because if words aren't legible enough, people increase the font size until they are. If something is extremely legible (like latin letters at a 40pt font size) people will naturally tend to decrease the size. So screen space and legibility are largely different labels for the same concept. With some wiggle room but not that much.

> There is probably a way to come up with dot positions that yield much nicer looking shapes.

Try it yourself!

http://dotsies.org/design-your-own

Hit the "random" link a few times and you'll get an idea of the possible variations. In the Dotsies pattern, vowels are at the tops and bottoms of words. The variations can look grainy, chunky, loopy, checker-board-ish (you'll see what I mean if you try it). The version I picked is a balance that leans toward being sparse and loopy, and is one of the many variations that has an intuitive letter ordering. Here's a decent one, but with a crappy ordering.

http://dotsies.org/design-your-own/#comeyhangrxdtwqpsfubzljv...

Surprisingly, none of them jump out as significantly better than the others (the overly dense ones being exceptions).

[from another comment] > I am pretty sceptical that an "optimized" alphabet glyph would be one dot for a b c d e, two adjacent dots for f g h i, etc.

There are other mappings that looked marginally better to me, but I deemed picking one with a nice ordering was worth doing. A and E happen to be the 1st and 3rd most common letters, which works out if you want to lean toward the sparse end. Also O (the 4th), A, and E all stick to the top and bottom edges of words, so if you want your words to tend to have holes in the middle they are a good fit. Getting a decent mapping for the commonest letters seems to be key, but by all means, try the above link and post an alternative that you think is better.

Grids of dots can be slightly morphed to resemble curves and slashes. Notice how some of the morphed versions of Dotsies appear visually similar to Asian scripts:

http://dotsies.org/script.html

Interestingly, when you read Dotsies quickly and at a smaller font size, the scripted versions appear indistinguishable from the square (unmodified) versions. Because of this I didn't end up pursuing this aspect.

Part of my motivation with Dotsies was to capture the compactness and visual distinctness of Asian characters, while still keeping what's good about alphabets. I'm guessing native Chinese speakers find it exhausting to have their eyes dart back and forth at a comparatively hectic speed to take in the same information when reading English?

Dotsies words look kind of like letters. They have lines, corners, loops, etc.

> There's going to be a high degree of uncertainty. A dot, and another dot 1 pixel higher or lower is easy to get conflated

I initially thought that would be a big issue as well. Turns out in practice it almost never comes up when reading paragraphs. For headings or words on signs that could be more of an issue.

I appreciate the support :)

Creator of Dotsies here. I've been using Dotsies to read books since 2012 (maybe around 100). At first on a Kindle and then on a Kobo after Amazon stopped letting you add your own fonts. I reached my normal reading speed a few years ago, and now reading it is fairly second nature. I now prefer it to normal fonts, and have the feeling that my eyes are racing unnecessarily from side to side when I use them. With normal fonts I'm also less likely to "seek" to different parts of the page, and thus feel a bit handicapped with them.

> the brain uses a hierarchy of constructs like circles, lines, corners, etc

It's a little counter intuitive if you haven't tried it, but the shape-seeking aspects of our visual systems do come into play with grids of dots. As others have said below, the words jump out at you as shapes. Sort of in the way that letters normally do. Just to approximate it, consider: :..'. But you may have to look at words a few thousand times before you get the full effect of this.

In general, the less visual noise and redundancy there is, the easier it is to recognize shapes. Consider looking at a pile of sand vs a pile of boulders, to get a sense of the extreme ends of this spectrum. Pile of sand: high complexity, harder to make out visual shapes. Pile of boulders: low complexity, easy to make out shapes. It is possible to map each letter to unique arrangements of 1000 disordered grains of sand, but clearly a few boulders per letter would be better. Consider that it takes about 20 pixels to represent each Latin letter. We scrapped reading fancy calligraphy because they would take more like 40px or so pixels to represent. And the extra flourishes really just added superfluity to the page. Only that was difficult for us to see, since we were so used to the calligraphy as the norm. I think it's naive to think the current state is the apex. Let's get rid of the remaining flourishes! Calligraphy is sand. Latin is marbles (or spaghetti might be apter). Binary grids are boulders. Just stare at the equivalent paragraphs under "How much better is it?" on dotsies.org for a while and you'll get a sense of this. (Especially if you can do so while imagining you're unfamiliar with Latin letters.)

I think I made a joke in 2012 about cave-men waving their spears at the stone-age version of hacker news claiming their bison heads and triangles couldn't possibly be improved on :).

Just wanted to give a quick summary. Will reply to other comments directly.

Btw I'm also the creator of Xiki, which has been discussed on HN as well, and has a stronger claim to originality/practicality. I did 2 kickstarters for it, which didn't get much hacker news attention, much to my disappointment. I'm doing a third soon and am hoping for more interest/abuse :). My new version will switch to using the markdown format, and will hopefully revolutionize the command line.

The Changelog. The topics are pretty diverse, with an emphasis on open source. I find myself listening to about half of them. Also Technotopia from John Biggs, about "a better future". The latter is more abstract but often worthwhile.

Btw reach out to me at @xiki on twitter if you're looking for a place...

After some pretty brutal feedback about my video last week, this is my Hacker News focused version. It gets right to the point.

1. Currently supports Aquamacs and Emacs. "Xiki-enabled text editor" means a text editor with a Xiki plugin installed. Which, in turn, means you can run Xiki commands right from that text editor (or IDE).

2. Yes, you need to be careful. Similar to being careful to which commands you paste into your shell, and which .sh files and scripts you run and which packages you install. It won't auto-run anything though. And since everything is plaintext, it should help people to review for malicious intent. Maybe some checking for special characters would be a good feature to add.

3. There's no way to preview. If you don't know what a command will probably do and don't trust the source, you probably shouldn't run it. There is a keyboard shortcut for jumping to the source code though!

4. Yes, you can run as non-root. The current version is a bit out of date, and has a rough install process (the Kickstarter is all about improving that). Currently you need ruby 1.9. I need to fix that soon - it probably won't be hard.

5. Ruby is a pretty decent language for manipulating text, and getting stuff done quickly, so it's a good fit for Xiki. You can make a Xiki command via a .py, .js, or .coffee file though, so you don't need to know ruby to make commands!

Thanks so much sunir! I love the unixy command line. I think there's a path to bringing command line haters and lovers together, to get us all creating and sharing commands that we can use with our UI method of choice.

The offer is still open. Let's pair! :)

I want to pair with a bunch of people during the campaign. I think misc pairing on open source projects is going to be a huge part of how we devs connect with each other. What better way to get familiar with a project super quickly than to pair with one of the core members. For the core members, the benefits include motivation, getting fresh ideas, and getting perspectives from new users.

Indeed! Thanks so much for the support!!

Sorry you don't like the music. I showed it to a bunch of people and they said good things about the music.

The music was actually created via the xiki "piano" command (and then enhanced with garage band). I was going to emphasize that but ran out of time... There are 16 backers so far (and only a few are friends) so hopefully it hasn't ruined it for everyone.

Hey! Project creator here! I'll answer all your questions here and try and clear up the writing. Ask away.

Thanks! :)

I posted this on the blog itself, but re-mentioning it here... I've been evolving Xiki for over 10 years to do be a language for doing this kind of thing. The ideas is you can interact with trees and other nested structures (file paths, dbs, general UI's) from your text editor, using a simple plaintext representation, but in a GUI-like manner.

I've done talks about Xiki at RubyConf, Strange Loop, and QCon. Here's a quick 3 minute video - https://www.youtube.com/watch?v=bUR_eUVcABg. I'm doing a Kickstarter campaign soon, to bring Xiki support to vim, sublime, and possibly other text editors!

Shows oscilliscope-like output from a microphone... woah. In other parts of the video he steps through a dsl that controls the LED, and it shows the code and controls the arduino as he scrolls through with his mouse. Check out 3:27, 3:57, 4:55, and 6:47.

Much of Xiki has recently been extracted out into the 'xiki' shell command though. So when the vim Xiki client works, a lot of stuff will work (most of the menus). It just needs to grab the path based on where the cursor is, pass it to the 'xiki' shell command, and insert the results into the vim window (indented 2 spaces lower).

If any vim user in the bay area are interested in getting together and pair programming on knocking this out, ping me on twitter! The current vim xiki proof of concept uses the vim ruby api, which is actually pretty decent.

If you're on a Mac, you install AquaMacs which is very mac-like (shift-arrow-key to select, type to replace, etc.) and doesn't require emacs skills.

Another option is for vim people is Viper mode, which emulates vim from inside emacs (a lot of people like it apparently).

Related note, I was pairing with someone on Monday at Proto Night (protonight.com) and we got a very simple TextMate xiki client mostly working.

Getting ready to jump on a train, but I'll try to pop in in a bit.

Hmm, I just got it running in a VM on 12.04 a few days ago. I'll try it again.

Cmd-return "launches" whatever line the cursor is on. It's analogous to what return does in a shell console. Ctrl-return and double-clicking do the same thing.

When you launch a $... shell command it executes it and inserts the results. When you launch a url, it opens it in the browser. When you launch a dir path it lets you navigate the dir contents, etc.

I saw a screencast of that lately. Pretty awesome stuff.

You can type to narrow down after running anything. And its all just text so you can delete whatever you want, to narrow down the output (not practical on most shell consoles).