Show HN: Tiled Text – a Different Approach to Editing Text(tiledtext.com)
tiledtext.com
Show HN: Tiled Text – a Different Approach to Editing Text
http://www.tiledtext.com/
29 comments
whoa missed that, the Boston market is booming right now. Its hard to find a good quality candidate.
It's crazy, what he has shown puts him clearly in the top 5% of developers. Such a waste to see him working in a grocery store.
The OP has RSI issues according to the last few paragraphs. I hope he can get his text editing system developed to where he can use it to edit text on a tablet screen efficiently and thus work in a commercial programming job.
"My studies at these times were very fruitfull and I think now that mathematics has a chance at contending with coding, and I have finally seen some glimpses of mathematical structures that should be called beautiful."
Could be an alternative path there.
"My studies at these times were very fruitfull and I think now that mathematics has a chance at contending with coding, and I have finally seen some glimpses of mathematical structures that should be called beautiful."
Could be an alternative path there.
Well RSI and CTS are quite closely related, and as someone who has latter I can say that touch screens are worst possible input device possible. All swiping gestures cause static strain, especially to wrists, which makes long time touch screen usage impossible. Even using touchpad gets painful fast, my laptop has to have "nipple" controller. Also all keyboards I use has to have clear actuation point so I can use as little strength as possible to type.
Game controllers are not better. Excerpt from wikipedia: "RSI is also used as an umbrella term for non-specific illnesses popularly referred to as Blackberry thumb, iPod finger, gamer's thumb"
Game controllers are not better. Excerpt from wikipedia: "RSI is also used as an umbrella term for non-specific illnesses popularly referred to as Blackberry thumb, iPod finger, gamer's thumb"
Hey Orva. Sorry to hear about the CTS :(
Something I've seen from speaking with a lot of people with overuse injuries is that what activates a person's injury tends to vary a lot. I'd heard elsewhere that touchscreens were terrible and didn't try them for quite a while as a result. But for me they ended up being better for a lot of things. Additionally, game controllers are a large improvement in my case simply because I can hold it in my lap instead of extending my arms, and in my case there is only limited finger pain (more arms, elbows, wrists).
The ideal here, however: are motion sensors--like the Kinect, but better. In fact I started out working with the Kinect, but it's not precise enough imo to create a nicely ergonomic coding system. However, things like The Leap (https://www.leapmotion.com/) may be: it could take very subtle cues as inputs and track light hand motion.
Something I've seen from speaking with a lot of people with overuse injuries is that what activates a person's injury tends to vary a lot. I'd heard elsewhere that touchscreens were terrible and didn't try them for quite a while as a result. But for me they ended up being better for a lot of things. Additionally, game controllers are a large improvement in my case simply because I can hold it in my lap instead of extending my arms, and in my case there is only limited finger pain (more arms, elbows, wrists).
The ideal here, however: are motion sensors--like the Kinect, but better. In fact I started out working with the Kinect, but it's not precise enough imo to create a nicely ergonomic coding system. However, things like The Leap (https://www.leapmotion.com/) may be: it could take very subtle cues as inputs and track light hand motion.
> Something I've seen from speaking with a lot of people with overuse injuries is that what activates a person's injury tends to vary a lot.
In hindsight this really makes sense. Mine was most likely activated by combination of low-profile keyboard and finnish keyboard layout (almost all programming related special characters are behind right alt combinations). So it's not suprise that all reaching motions are not good.
> The ideal here, however: are motion sensors--like the Kinect, but better.
Kinect depth sensor has really low resolution (640x480, if I remember correctly) which is way too low if you want to interpret precisely small movements. I also was interested about Kinect for exactly same purpose, but those specs were too "meh". For this reason I have been waiting for Leap to be released since its announcement.
In hindsight this really makes sense. Mine was most likely activated by combination of low-profile keyboard and finnish keyboard layout (almost all programming related special characters are behind right alt combinations). So it's not suprise that all reaching motions are not good.
> The ideal here, however: are motion sensors--like the Kinect, but better.
Kinect depth sensor has really low resolution (640x480, if I remember correctly) which is way too low if you want to interpret precisely small movements. I also was interested about Kinect for exactly same purpose, but those specs were too "meh". For this reason I have been waiting for Leap to be released since its announcement.
I've learned from this as a 'casual' user of computers.
What are the alternatives? Speech to text? DataHands? (http://www.datahand.com/products/proii.htm)?
Would you recommend a mechanical switch keyboard?
What are the alternatives? Speech to text? DataHands? (http://www.datahand.com/products/proii.htm)?
Would you recommend a mechanical switch keyboard?
he's already presented more than enough to get a commercial programming job. having a vision and executing it publicly and not having it fall down is rather rare, regardless of how awesome the end result is. For the record, I only took a brief look I likes my normal text editor.
I like the way people are starting to look at alternative approaches to text editing. Light Table has some good ideas, for example. For me, multiple cursors and fast symbol navigation in Sublime Text has been a huge time saver.
Personally, I have never needed code folding (I prefer to have my own map of the code in my head, and anything that obscures that map just gets in the way), or Sublime Text's minimap, nor have I ever needed the symbol sidebar that is found in some IDEs (Eclipse, Netbeans). What I really want is more efficient editing.
For example, text editors like Sublime have zero language-sensitive refactoring support. I can't rename (variables, methods etc.) or extract methods, for example. Even some really simple operations like "select entire current nesting level" are unavailable. I remember using Eclipse 7 years ago and really liking the intelligence of the incremental compiler backend, even though I hated Java; it seems that with backends such as Clang, those tools can once again be applied outside big, annoying IDEs like Eclipse and Xcode.
Not sure if this particular approach is useful except to a small niche, but it looks pretty slick. Good luck with the effort!
Personally, I have never needed code folding (I prefer to have my own map of the code in my head, and anything that obscures that map just gets in the way), or Sublime Text's minimap, nor have I ever needed the symbol sidebar that is found in some IDEs (Eclipse, Netbeans). What I really want is more efficient editing.
For example, text editors like Sublime have zero language-sensitive refactoring support. I can't rename (variables, methods etc.) or extract methods, for example. Even some really simple operations like "select entire current nesting level" are unavailable. I remember using Eclipse 7 years ago and really liking the intelligence of the incremental compiler backend, even though I hated Java; it seems that with backends such as Clang, those tools can once again be applied outside big, annoying IDEs like Eclipse and Xcode.
Not sure if this particular approach is useful except to a small niche, but it looks pretty slick. Good luck with the effort!
After using Sublime for a little over a year now, I've found the minimap is not useful as a map per se, but I do find it handy for two things. First, it's an omnipresent 'fingerprint' of the file I'm looking at, and I think subconsciously it helps me get my bearings when I switch files. Second, it's a nice fat, instant scroll bar for moving around a file quickly (which, yes, I do occasionally even with all the nice fuzzy search tools).
When I first started using ST, I thought the map would be really helpful. In the end, I typically use it the way you do...as a sort of placeholder and scrollbar. However, the ctrl-R feature has become my go-to tool for finding a subsection quickly. Really useful, I've found.
"ctrl-R"..... I love you. Thank you.
I have tried using it, but I always find it a distracting presence. I know my files exceedingly well, and those that I don't know, I learn very quickly.
On the other hand, I have colleagues who can't program without having pen and paper around -- people use whatever tools they like based on how their mind works.
On the other hand, I have colleagues who can't program without having pen and paper around -- people use whatever tools they like based on how their mind works.
Sublime's "Selection > Expand Selection to Brackets" (which can be repeated) is effectively nesting level selection for bracey languages. I do get what you're saying about the feeling of text manipulation vs. code-aware text manipulation though.
Emacs has a nice package called expand-region[1] which works in a similar, although more context-sensitive fashion. There's a nice intro screencast by Emacs Rocks[2] as well.
The context-sensitivity is handled by having a list of expansion/contraction functions to try in sequence, so your region grows outwards by different units. Or you can specify a specific expansion function (like, er/mark-outside-python-string) upfront.
As an example, the expand function list I have for a python buffer open is:
[2] http://emacsrocks.com/e09.html
The context-sensitivity is handled by having a list of expansion/contraction functions to try in sequence, so your region grows outwards by different units. Or you can specify a specific expansion function (like, er/mark-outside-python-string) upfront.
As an example, the expand function list I have for a python buffer open is:
(er/mark-word
er/mark-symbol
er/mark-symbol-with-prefix
er/mark-next-accessor
er/mark-method-call
er/mark-inside-pairs
er/mark-outside-pairs
er/mark-comment
er/mark-inside-python-string
er/mark-outside-python-string
er/mark-python-statement
er/mark-python-block
er/mark-python-block-and-decorator
er/mark-outer-python-block)
[2] http://emacsrocks.com/e09.html
Very cool.
Indeed, although that one is useless if you want to do something like wrap the current statement in an "if" or "while" or similar. "Expand Selection to Brackets" will actually include the lines containing the brackets, so you can't use it to select the contents of a block.
Sublime also has "Expand Selection to Scope", except it doesn't really work that well: First invocation it chooses the current symbol, on 2nd the current brace block except the braces, on 3rd the braces themselves, and so on.
And it also has "Expand Selection to Indentation", but I don't see use for it in cases where you want to manipulate blocks of code, since it nearly always doesn't select what you want.
What I'd like is a command, let's call it "Expand Selection to Statement or Block", that:
* On 1st invocation, selects the current line.
Combined with a "wrap selection in braces"-type command (that indented the selection, wrapped it in braces, and placed the caret at the beginning so you could start typing something like "if (...) {") you would have a fairly powerful block-manipulating shortcut.
It would probably be quite trivial to write such a plugin. I might try my hand at this. Not sure how much language sensitivity it would need, might be doable without anything at all.
Sublime also has "Expand Selection to Scope", except it doesn't really work that well: First invocation it chooses the current symbol, on 2nd the current brace block except the braces, on 3rd the braces themselves, and so on.
And it also has "Expand Selection to Indentation", but I don't see use for it in cases where you want to manipulate blocks of code, since it nearly always doesn't select what you want.
What I'd like is a command, let's call it "Expand Selection to Statement or Block", that:
* On 1st invocation, selects the current line.
int foo(int bar) {
bar = mogrify(bar);
if (bar > 0) {
slartibartfast = 42;
[[baz = bar + 1;]] # <-- [[ selection ]]
print_report();
}
return bar;
}
int foo(int bar) {
bar = mogrify(bar);
if (bar > 0) {
slartibartfast = 42;
[[baz = bar + 1;
print_report();]]
}
return bar;
}
int foo(int bar) {
bar = mogrify(bar);
if (bar > 0) {
[[slartibartfast = 42;
baz = bar + 1;
print_report();]]
}
return bar;
}
int foo(int bar) {
bar = mogrify(bar);
[[if (bar > 0) {
slartibartfast = 42;
baz = bar + 1;
print_report();
}]]
return bar;
}
int foo(int bar) {
bar = mogrify(bar);
[[if (bar > 0) {
slartibartfast = 42;
baz = bar + 1;
print_report();
}
return bar;]]
}
Combined with a "wrap selection in braces"-type command (that indented the selection, wrapped it in braces, and placed the caret at the beginning so you could start typing something like "if (...) {") you would have a fairly powerful block-manipulating shortcut.
It would probably be quite trivial to write such a plugin. I might try my hand at this. Not sure how much language sensitivity it would need, might be doable without anything at all.
Good explanation. Thanks.
Talking of contiguous lines. I like macros of the following form for quickly hopping around vertically in a file:
Talking of contiguous lines. I like macros of the following form for quickly hopping around vertically in a file:
// .sublime-macro
[
{"command": "move", "args": {"by": "stops", "empty_line": true, "forward": false}}
]
// .sublime-macro
[
{"command": "move", "args": {"by": "stops", "empty_line": true, "forward": false, "extend": true}}
]
// .sublime-keymap
{ "keys": ["ctrl+up"], "command": "run_macro_file", "args": {"file": "Packages/User/HopUp.sublime-macro"} }
{ "keys": ["ctrl+shift+up"], "command": "run_macro_file", "args": {"file": "Packages/User/HopUpSelect.sublime-macro"} },Very nice, I'm copying that one! You don't actually have to use macros for that. This will suffice (in your .sublime-keymap):
{"keys": ["alt+up"], "command": "move", "args": {"by": "stops", "empty_line": true, "forward": false}},
{"keys": ["alt+down"], "command": "move", "args": {"by": "stops", "empty_line": true, "forward": true}},
{"keys": ["shift+alt+up"], "command": "move", "args": {"by": "stops", "empty_line": true, "forward": false, "extend": true}},
{"keys": ["shift+alt+down"], "command": "move", "args": {"by": "stops", "empty_line": true, "forward": true, "extend": true}},
Oops. Right enough. It was in its own file because before I knew about stops+empty_line, the macro was simply a compound equivalent to pressing up 4 times.
IntelliJ IDEA has both "expand selection outward" and "wrap selection in if/trycatch/while/etc" functions. They both work pretty much how you describe them here. They're language-dependent, too, so they work in any language that the IDE can understand internally.
Thanks for the tip. I am not interested in switching from Sublime to something like IDEA, though.
(IDEA is a Java/Swing app, and I'm very sensitive to apps that don't look or feel native on OS X. Yes, Sublime is crude in places, but at least looks and feels native. Being a Swing app it promotes certain GUI conventions that have not been relevant since the early 2000s. It's tabs and toolbar hell and looks like something out of a bad Windows nightmare. Sorry if that sounds snobby, but if I didn't like beautiful GUIs I would not be using a Mac.)
(IDEA is a Java/Swing app, and I'm very sensitive to apps that don't look or feel native on OS X. Yes, Sublime is crude in places, but at least looks and feels native. Being a Swing app it promotes certain GUI conventions that have not been relevant since the early 2000s. It's tabs and toolbar hell and looks like something out of a bad Windows nightmare. Sorry if that sounds snobby, but if I didn't like beautiful GUIs I would not be using a Mac.)
So you sacrifice usability for how pretty you find the IDE's gui?
I don't know what others do, but I actually hide the toolbars in my IDEs (I use several JetBrains products: PyCharm and IntelliJ mostly, PHPStorm and RubyMine to a lesser extent.) PyCharm actually received a facelift recently that I hope finds its way to the other products as well.
All JetBrians products ship with several skins (ctrl+tilde brings up the menu) and I've never found any trouble getting them the way I want. I do find XCode (which is my go-to editor for C and C++ not being an ObjectiveC developer myself) to be a very good looking IDE but personally, I'd never sacrifice function. It's just too important. IMHO, of course.
I don't know what others do, but I actually hide the toolbars in my IDEs (I use several JetBrains products: PyCharm and IntelliJ mostly, PHPStorm and RubyMine to a lesser extent.) PyCharm actually received a facelift recently that I hope finds its way to the other products as well.
All JetBrians products ship with several skins (ctrl+tilde brings up the menu) and I've never found any trouble getting them the way I want. I do find XCode (which is my go-to editor for C and C++ not being an ObjectiveC developer myself) to be a very good looking IDE but personally, I'd never sacrifice function. It's just too important. IMHO, of course.
No, I do not.
Xcode is also native (although not very pretty), but it is a horrible IDE. I use Sublime for my ObjC coding, although I am forced to use Xcode for some things that ST cannot do, like adding files to a project, editing compilation flags or working with .xib and Core Data .momd files.
It's a compromise. IDEA is too ugly to use, Sublime lacks some features but is great in most areas.
Xcode is also native (although not very pretty), but it is a horrible IDE. I use Sublime for my ObjC coding, although I am forced to use Xcode for some things that ST cannot do, like adding files to a project, editing compilation flags or working with .xib and Core Data .momd files.
It's a compromise. IDEA is too ugly to use, Sublime lacks some features but is great in most areas.
Not to debate you, because hey, it's your perogative. But I want to just ask this though and give you the last word with it:
Given that many of the features you're talking about actually do exist in IntelliJ, etc, doesn't that mean that yes, you are sacrificing function for form?
Given that many of the features you're talking about actually do exist in IntelliJ, etc, doesn't that mean that yes, you are sacrificing function for form?
Yes, it's a compromise. It's not all about function, or all about form. If ST is 90% beautiful, and IDEA is 0% beautiful, then I will choose Sublime even if it's 5% less functional.
There are other factors at play such as speed; Sublime is lightning fast, IDEA is not. And afaik, IDEA does not support Sublime-style multiple carets.
There are other factors at play such as speed; Sublime is lightning fast, IDEA is not. And afaik, IDEA does not support Sublime-style multiple carets.
It really depends on what you're doing. For me (Java), IDEA is about 50% beautiful but 500% functional, and that's what leaves me with it.
Vim does a very good job of this:
vi{
v%> Even some really simple operations like "select entire current nesting level" are unavailable.
For anyone else looking for exactly this, here's a great vim extension that gives you "indent" objects: http://www.vim.org/scripts/script.php?script_id=3037
For anyone else looking for exactly this, here's a great vim extension that gives you "indent" objects: http://www.vim.org/scripts/script.php?script_id=3037
This is a cool toy but it doesn't really seem to address the main issue of writing code on a touch device; typing on a touch device sucks.
Moving code around is not a difficult problem to solve. Drag to highlight, grab it and move it somewhere else. You've done that elegantly.
But writing massive amounts of code on a device without a traditional keyboard is awful and that's the difficult problem to solve. Until that's solved I don't think anyone can claim to have made real progress enabling development on keyboardless devices.
Moving code around is not a difficult problem to solve. Drag to highlight, grab it and move it somewhere else. You've done that elegantly.
But writing massive amounts of code on a device without a traditional keyboard is awful and that's the difficult problem to solve. Until that's solved I don't think anyone can claim to have made real progress enabling development on keyboardless devices.
On the contrary, selecting, cutting and pasting text is awfully cumbersome (on iPhone), together with placing the cursor in the desired spot, but typing is almost ok, and on the iPad I can type normally - it's the editing that doesn't work well.
If only your phone had an Xbox controller!
Are you thinking what I'm thinking? http://i.imgur.com/1d2F6Ot.jpg
PD: Apple please don't sue me for the patent and copyright violation this may contain; I have no money and this image is just a non-profit parody so it is covered by "fair use" under US trademark law.
PD: Apple please don't sue me for the patent and copyright violation this may contain; I have no money and this image is just a non-profit parody so it is covered by "fair use" under US trademark law.
from the page:
"What's not There (Yet): Text generation: with sufficiently structured text, the Tiled Text engine will narrow down the possibilities of what can be inserted at any given point so that the user can select textual constructs from a grid of options, rather than inserting everything one character at a time (this won't work for natural languages; it's for apps like shells and code editors, and perhaps some more exotic things). The engine for doing this is at ~(70% - 80%), but it has not been attached to the UI yet ..."
It'll be there soon!
"What's not There (Yet): Text generation: with sufficiently structured text, the Tiled Text engine will narrow down the possibilities of what can be inserted at any given point so that the user can select textual constructs from a grid of options, rather than inserting everything one character at a time (this won't work for natural languages; it's for apps like shells and code editors, and perhaps some more exotic things). The engine for doing this is at ~(70% - 80%), but it has not been attached to the UI yet ..."
It'll be there soon!
I'd love to see more editors/IDEs that operate at a higher semantic level than plain text. The biggest problem is of course interoperating with existing language/development ecosystems. I have pondered in the past about a language or platform where everything is stored internally as some form of AST, and text is just one of the possible representations. It would at least solve the coding-style (well, the formatting part at anyway) issue for once and for all; everyone just maintains their own CSS/XSLT-alike transforms with tabs or spaces and brackets and semicolons wherever they like.
I've come across occasional research projects in 'structural editors' which only allow semantically correct input (and, depending on the size of the input alphabet, can function through almost 100% autocomplete menu input)
Anastasia[1] is one that I know of, and this Modeless Structure Editing by Sufrin et al.[2] looks interesting.
The main issue I can see, apart from the effort involved, is how to deal with incomplete documents, since almost by creation or editing process will have interim invalid structures. Emacs paredit can be pretty infuriating if you don't use its specialised operations and try to edit your code in a way that malforms the structure.
[1] http://dream.inf.ed.ac.uk/projects/anastasia/
[2] http://www.cs.ox.ac.uk/bernard.sufrin/edit.pdf
I've come across occasional research projects in 'structural editors' which only allow semantically correct input (and, depending on the size of the input alphabet, can function through almost 100% autocomplete menu input)
Anastasia[1] is one that I know of, and this Modeless Structure Editing by Sufrin et al.[2] looks interesting.
The main issue I can see, apart from the effort involved, is how to deal with incomplete documents, since almost by creation or editing process will have interim invalid structures. Emacs paredit can be pretty infuriating if you don't use its specialised operations and try to edit your code in a way that malforms the structure.
[1] http://dream.inf.ed.ac.uk/projects/anastasia/
[2] http://www.cs.ox.ac.uk/bernard.sufrin/edit.pdf
Here's another example of operation at a higher level: http://subtextual.org/subtext2.html
That was an interesting demo, thanks for the link. I can imagine it as a replacement or view onto the standard spreadsheet, and potentially as a learning tool for logics.
I'm not sure how it would scale though, perhaps in a collapse/expand fashion similar to the current 'focus' mechanism, or some sort of level-of-detail aware zoom that progressively replaces chunks with higher level representations.
The author also notes on the main subtextual.org site about issues of mutable state, but it's definitely an interesting take on language design, and may (hopefully) not share the same death-by-layout-complexity fate most visual languages eventually suffer.
I'm not sure how it would scale though, perhaps in a collapse/expand fashion similar to the current 'focus' mechanism, or some sort of level-of-detail aware zoom that progressively replaces chunks with higher level representations.
The author also notes on the main subtextual.org site about issues of mutable state, but it's definitely an interesting take on language design, and may (hopefully) not share the same death-by-layout-complexity fate most visual languages eventually suffer.
Great video! Scalability is the obvious issue though.
Could doctors use a gestural interface like this to write templated notes in an EMR on touch devices? Most of the notes that doctors write have repetitive structures. Hence, EMRs like Epic have come up with features like Smart Text, which expand special phrases into large templated sentences with certain bits of data prepopulated and keywords that can be toggled between values (present/absent, etc.) with the keyboard.
But the key complaint with these EMRs is that you need to type to use them, which is awkward and breaks the flow of conversation with a patient. Eye contact is important during patient interviews. Therefore, most doctors use paper and type them into the EMR later (waste of time).
A lot of people (and companies like drchrono) think that the way forward is to use tablets like the iPad mini or the Galaxy Tab, which balance the intrusiveness of the computer form factor against the ability to enter data. A pain point of tablet EMRs is text entry--but like I said, a lot of notes that doctors write have predefined structures, like code.
I think there is potentially a lot of money in elegantly solving this UI problem with a new interface like Tiled Text.
But the key complaint with these EMRs is that you need to type to use them, which is awkward and breaks the flow of conversation with a patient. Eye contact is important during patient interviews. Therefore, most doctors use paper and type them into the EMR later (waste of time).
A lot of people (and companies like drchrono) think that the way forward is to use tablets like the iPad mini or the Galaxy Tab, which balance the intrusiveness of the computer form factor against the ability to enter data. A pain point of tablet EMRs is text entry--but like I said, a lot of notes that doctors write have predefined structures, like code.
I think there is potentially a lot of money in elegantly solving this UI problem with a new interface like Tiled Text.
(Sorry this is so short/badly explained. I'm typing this from my phone)
I've worked for an EHR company that has had a solution to this problem for at least a half decade. Basically, there's a specialized touch screen input interface that is customized to the specific text field the doctor is imputing ino. It works similarly to smart text, but is much quicker, as the doctor is just selecting an option on a touchscreen instead of having to begin by typing. It, of course, has programmed text sequences and can have custom values imputed. From what I know, it works really well in the field.
That is a great idea. I have figured that there must be a ton of little niche areas for working with structured text like that--just waiting to discover more of them.
This is a very cool project, nice work. It seems to be very similar to an older project for Emacs named Versor[1]. There's an interesting document out there talking about how to operate Emacs and Versor using a gamepad[2], similar to how you're doing here. It seems that Versor eventually compromised on entering necessary text with a real keyboard and using the gamepad for all navigation and other editing purposes. I actually had a weeks-long thought experiment involving Versor and a 3d-printed gamepad with a chording keyboard on the back. It never went anywhere, but it was fun to think about.
[1]: http://emacs-versor.sourceforge.net/
[2]: http://www.cb1.com/~john/computing/emacs/emacs-gamepad.html
[1]: http://emacs-versor.sourceforge.net/
[2]: http://www.cb1.com/~john/computing/emacs/emacs-gamepad.html
I don't get it... He's trying to solve the problem of typing text in a touch device... with an XBox controller? why not better carry a small keyboard?
The program looks awesome, but i believe it would be more productive to have this features on a regular IDE where you can actually use the keyboard... All the movement between nodes looks terrific.
But anyway...
The program looks awesome, but i believe it would be more productive to have this features on a regular IDE where you can actually use the keyboard... All the movement between nodes looks terrific.
But anyway...
He has RSI from using the keyboard, so making the editor work with a controller first makes sense because he is the only person using his program at the moment.
He addresses that in the Why at the bottom.
He developed carpal tunnel or some other wrist aliment, and can't type for any real amount of time on a keyboard, apparently using an xbox controller is easier but really he wants to move to using the kinect.
He developed carpal tunnel or some other wrist aliment, and can't type for any real amount of time on a keyboard, apparently using an xbox controller is easier but really he wants to move to using the kinect.
This is really neat, great work! I wonder, do people perform the kind of edits that this makes efficient very often?
For example, in the video it was predetermined exactly what was going to be moving and where it was going to go to. From my observations, these sorts of large scale changes are rarely handled so easily. Context helps people map things cleanly, and the contextual change of zooming in and out forces you to constantly rebuild that map. It's an issue I've seen over and over again with any zoom-oriented interface.
Regardless, this is cool work. We need new and interesting interfaces for code - I'm hoping to show some fun things myself at the Live Programming Workshop [1] at ICSE[2].
[1]: http://liveprogramming.github.com/2013/ [2]: http://2013.icse-conferences.org/
For example, in the video it was predetermined exactly what was going to be moving and where it was going to go to. From my observations, these sorts of large scale changes are rarely handled so easily. Context helps people map things cleanly, and the contextual change of zooming in and out forces you to constantly rebuild that map. It's an issue I've seen over and over again with any zoom-oriented interface.
Regardless, this is cool work. We need new and interesting interfaces for code - I'm hoping to show some fun things myself at the Live Programming Workshop [1] at ICSE[2].
[1]: http://liveprogramming.github.com/2013/ [2]: http://2013.icse-conferences.org/
Yes, the loss of context can be an issue--definitely. I hesitated to include the code collapsing/expanding aspects in the demo because it disguises something more important that's going on, which is unit selection. If I disable collapsed nodes, then when you 'enter' a function you would just see the tile boundaries change from being around each function to being around each line in the function.
Hadn't heard of those workshops -- will take a look.
Hadn't heard of those workshops -- will take a look.
In answer to your first question: I think these edits will have to be supplemented by more traditional operations, like forming selections based on textual search criteria for instance. So it's definitely not enough on its own--but it's important because when you do have to do this sort of thing, you can do it efficiently through an interface to the text that's consistent with contemporary tile-based ui.
The image at the top of the page almost made me close the tab instantly. It's the polar opposite of slick and intuitive.
I did stick around though and the video does look very nice, but I would recommend a more inviting first impression (I realize this is a library for developers, but still).
I did stick around though and the video does look very nice, but I would recommend a more inviting first impression (I realize this is a library for developers, but still).
With all due respect, "slick and intuitive" is entirely the wrong requirement for a programmer's text editor. This is a tool that you will use for 60-100% of every day. There is absolutely zero value to "intuitive" with serious editors -- a feature that you can't use from muscle memory might as well not exist.
No one would ever call vim or emacs "slick", yet they own the market among the most expert users. That is not a coincidence.
No one would ever call vim or emacs "slick", yet they own the market among the most expert users. That is not a coincidence.
> ... the Tiled Text engine will narrow down the possibilities of what can be inserted at any given point so that the user can select textual constructs from a grid of options, rather than inserting everything one character at a time ...
The recently revamped PSN Store on PS3 has what I thought was quite a usable implementation of text entry. When searching the store, you select characters one at a time from a (vertical) strip, but that dynamic strip only contains characters for which there will continue to be search results after it's appended to your string. The current search results are shown as a live preview, so you need enter just enough to filter out the noise.
The recently revamped PSN Store on PS3 has what I thought was quite a usable implementation of text entry. When searching the store, you select characters one at a time from a (vertical) strip, but that dynamic strip only contains characters for which there will continue to be search results after it's appended to your string. The current search results are shown as a live preview, so you need enter just enough to filter out the noise.
it reminds me of TomTom and other car GPS systems text input methods, in which keyboard keys are gradually grayed out as the user inputs their destination, if there are no matches for which that key is the next letter
That is similar, except that I do the filtering on a grammatical basis. I'm curious though: will take a look.
This is hardly a new idea though. Half of car navigation systems implement this exact type of entry method.
I've just download Vim Touch (https://play.google.com/store/apps/details?id=net.momodalo.a...) and have been playing around with it for a bit. And I can attest to the fact that editing on a phone is incredibly painful. Once I realized that, though, I also realized that there is very little need for me to ever need to edit code on my phone. So, I see and acknowledge the conceptual problem that Tiled Text is trying to solve but I fear that the audience is far too small for it to be of much use.
It's more general than for just editing code (a code editor is just all I've built so far): editing English documents by manipulating the units: paragraph, sentence, clause/phrase, word, character -- is the primary application I see for it (Unfortunately I didn't think of this until far into the code editor :)
Note that the author says, on the web page:
> ... I wrote Tiled Text to get around a mouse/keyboard injury I have ...
So this is not necessarily intended for everyone.
> ... I wrote Tiled Text to get around a mouse/keyboard injury I have ...
So this is not necessarily intended for everyone.
Given that tablets and smart phones are taking over as ubiquitous computing devices on the contrary I think the need for alternate text inputs is growing rapidly.
I've had an interesting experience using swype on nexus 7. I find my concept of spelling itself is changing'where creating a word is more about the shape than specific correct spelling. Using swype effectively still requires knowledge of how words are spelled and layed out on the QWERTY keyboard. But I see it pointing towards gestural text creation.
I've had an interesting experience using swype on nexus 7. I find my concept of spelling itself is changing'where creating a word is more about the shape than specific correct spelling. Using swype effectively still requires knowledge of how words are spelled and layed out on the QWERTY keyboard. But I see it pointing towards gestural text creation.
vim is actually the only reason I'm willing to do editing in a browser. Having used vim and ex commands for over half of my life, combined with the fact that I actually spend more time thinking about what I want to do rather than typing (pretty sure most of you do the same), makes a command-oriented editor (vim's normal mode) perfect on the go.
I actually like Vim Touch with Hacker Keyboard on my Nexus 7.
I actually like Vim Touch with Hacker Keyboard on my Nexus 7.
It would be really cool to see an integration of this with the Leap Motion controller (http://leapmotion.com/). I can't imagine writing code exclusively with Tiled Text gestures, but the idea of moving around, navigating, and manipulating text with gestures when it make sense, then typing when that's the most effective - and going fluidly between the two - that sounds really incredible.
Congrats on building this! I wonder, have you considered speech recognition as an alternative source for text generation? You could build some powerful voice commands this way, possibly rivaling Vim, TextMate etc.
We will eventually see some growth in demand for text editing on tablets and phones. With some further research and innovation, you may be able to turn this into a tool (possibly commercial) that is useful for a larger audience.
We will eventually see some growth in demand for text editing on tablets and phones. With some further research and innovation, you may be able to turn this into a tool (possibly commercial) that is useful for a larger audience.
Exactly! That's what I've had my eye on for a while, but most people I've spoken with don't see it this way. I have a good scheme for editing English documents using punctuation and newlines etc. for informing tile boundaries -- and using voice recog. or other (selectable) systems for insertion.
Thanks for the comment -- reassuring to hear someone else envisioning that path.
Thanks for the comment -- reassuring to hear someone else envisioning that path.
Blocks in 3D would be neat. Gives you an instant representation of the depth of inner loops/blocks/closures/function bodies.
I wonder if we'll have that at some point.
I wonder if we'll have that at some point.
Nice. Was vi-style modal editing a significant inspiration? It seems like it must have been. Definitely neat to see an approach to the same kind of limited-terminal constraints brought to modern devices. I don't know if I'd use it as a primary interface, but as a high level tool for code organization it could potentially justify having a touch screen on a code editing machine.
I've been meaning to learn vi, but still haven't gotten around to it :) So I can't say that it was much of an inspiration for what's there. Interestingly though, the way that it sequences commands so that they could be described by a grammar has inspired important parts of the program that haven't been incorporated yet...
Although our company is from Lebanon, so we'd basically be pulling ourselves to compete with your groceries job, I believe I can convince our company to offer you a job.
You can thank the sheer chutzpah of your person, that allowed you to create this editor.
Let me know if you're interested, so that we can discuss the details :)
This is very innovative. Constraint does force invention.
Often time I wish I can write some code on my phone but gave up after a while due to the painful editing process. It looks like it can help a lot. Looking forward to further development.
Often time I wish I can write some code on my phone but gave up after a while due to the painful editing process. It looks like it can help a lot. Looking forward to further development.
Cool. Have you considered also tokenizing camelCase text into separate words?
Congrats. A very interesting an innovative approach.
It would be nice to have sound effects like that in Sublime Text.
If anyone is interested, I'd be glad to write a plugin together.
I watched the video and still have no idea what this is about - someone explain it in english?
have you considered using APL and its derivatives ? it's about 100x less typing than java.
I haven't looked very closely at APL, though I have been thinking that for reasons of suitability for Tiled Text, and for less typing with traditional editors -- it's probably worthwhile considering a language that can figure out more on its own... I'll take another look at APL.
I definitely want to try it with MYO wireless control, mostly for WOW effect.
i like the debug mode. being able to manipulate the tree directly seems like it could be more efficient than a cursor.
Someone get this man a job, even if it has nothing to do with this code.