The home page needs bigger calls to action. I wasn’t confident about the screencast link being useful because it was so small. I also had to hunt for the installation link – it turns out it’s under the “Code” section.
The “hero unit” at the top should contain a big link to install it (appropriately worded to indicate that it’s just sending you to instructions in a README on GitHub). Another big button link to the screencasts would probably help, since most people won’t understand what Xiki is without them. Alternatively, have a “features” page with a list of features and large, static screenshot demonstrating each of them.
Or how about at least some idea of what doing whatever you'd be doing, does? For example:
"Type and double-click Type a word, any word. Then double click on it or type control-return (or command-return). For example type: git, bootstrap, mysql, mongo, rails, node, coffee, js, dom, jquery, svg, ruby code, file paths, url's, shell commands, etc."
I can type and double click on any word in this text box. It doesn't do anything, but I can poke at them all I want. Or, how about this:
"Wiki inspired Everything is editable text. Type commands anywhere. Edit the output. (Vs. typing commands at the bottom, and read-only output.) Intermix menus, headings, bullet points, wherever you want. Xiki == executable wiki."
Why would I want to do any of that? Edit the output of commands?
Yeah, I love the idea, but I had to hunt for the install for a while too.. For a second I started to wonder if this was another good kickstarter idea that was unlikely to ever come to pass... very happy that is not the case.
Maybe I lack imagination, but even though the tool provides many interesting solutions, it doesn't seem to "scratch an itch" for any problems I need to solve.
The screencast narrator asks a number of intriguing "what if you could XYZ" questions, but it doesn't actually answer them, leaving the listener to come up with useful applications. Well, what if I could do all those things? I would like to have heard more about what higher-level problem(s) these solutions address, and why these are better solutions than what I'm already using. Something motivated the developer(s) to write this, but I can't immediately tell what that motivation was.
You don't lack imagination, but I bet you didn't really try to think about what you could do.
When you first dive into Linux, you learn that you have a thousand different simple commands. And you feel kinda lost. Then you start using them in ways their programmers never imagined. And you chain them with pipes and do some really cool shit.
You do that because nobody told you what they were for, they just were.
There are other screencasts on xiki.org/screencasts that go into detail about specific scenarios. Some of them are a little out of date but the general idea is till the same. The one on web development is decent but needs an update. More screencasts to come soon.
I've gotten similar feedback, re imagining what it would be used for. The simplest use case is probably the "shell terminal but better" one. You can narrow down the output of shell commands, and make reusable files with notes as you run stuff (for yourself to use later on, or for other people). You can nest the commands underneath directory paths to avoid having to CD. You can change parts of the paths to re-run the same commands in a parallel dir structure in a different place (even a remote server). You can search command history in a specific dir and re-run commands (vs bash history showing you commands that were run in any dir). You can post any notes you made on the web or email them to people, for others to help others get started using stuff.
Going a bit higher-level, Xiki sort of lets you have "paths" (kind of analogous to url's) for many different things - database records, running commands in specific dirs, running a line of javascript in your browser, changing the style of a div, firing off a button click on a web page given its id, running unit tests, showing runnable (and modifiable) example code for various frameworks, etc. Most people probably agree that having paths for files and web pages is pretty useful. Having paths to other things can be useful for many of the same reasons.
As much as I love to see people iterate on the boring old command line, this will never catch on.
1) It's too difficult to remember all the tricks to make it useful, and the cost of memorizing tricks that I saw in the first screencast isn't worth the efficiency it provides.
2) It's too difficult for new users to remember the tricks that are supposedly "better." It's a lot like Python vs. Perl -- Perl is a really smart and clever language, but you can type just a few characters more to write Python and it'll be a lot clearer as to what's going on.
The one exception to all of this is the MySQL stuff I saw. The MySQL prompt has sucked for a long, long time, and building SQL queries is something you do iteratively anyway.
All of the above said, I still think this is pretty neat. But I won't use it.
It may gain a following yet. There are two schools of thought when it comes to productivity tools such as shells, editors, and programming languages. Some think they should be optimised for ease of learning; others, instead for power and efficiency to those who already know them.
As a user of Emacs, Blender, and Perl, I’m probably in the latter camp. And this tool seems like something I might enjoy using. But I don’t think that, as a rule, things should be designed this way unless there’s a very good reason to do so, backed by user research. I would not design a programming language like Perl, for example, because “people who program” will always outnumber “programmers” and it’s best to cater to the majority.
I'm using "PLSQL Developer" at work instead of console prompt (sqlplus in my case), and it works in similiar way to xexi (but the results are in tabbed, excel-like grid in the bottom - you can edit it, sort, filter, etc, instead of right inside the main window). But the interaction is similiar to that of screencast - you write a few queries in the main window, click and CTRL+ENTER to run a query, you can at any time change them like in normal editor, or edit results and save them if you want.
It works great, much faster than regular prompt. Shame it's only for oracle db.
> 2) It's too difficult for new users to remember the tricks that are supposedly "better." It's a lot like Python vs. Perl -- Perl is a really smart and clever language, but you can type just a few characters more to write Python and it'll be a lot clearer as to what's going on.
Doesn't this same argument lead to the conclusion that new users won't use Perl over Python or --to put it more inflammatorily-- that Python killed Perl? This is surely demonstrably incorrect.
Exactly my thought. Executing any text anywhere, browsing directories with a clip, so much of that demo made me wonder if the author had ever seen Acme or if it was an example of parallel evolution.
I guess I could give emacs a shot, just whenever I've seen people use it it looks like they're pressing a shitload of keys to do the most basic of stuff, despite having amazing macros to do rather complex stuff.
But aside from that, this looks fantastic, it'd be interesting to see if more text editors could be ported to it (e.g. Sublime Text 2)
I've got a hobby project that I work on on and off that's similar (although I'm a vim guy no evil mouse clicks) with a heavy org-mode influence. Some of the features you demo in your screencasts are inspired.
I'll be following Xiki closely and probably stealing some of your ideas for my own project.
Good work, I'm glad to see people experimenting with new ideas in modern keyboard based power user interfaces.
While it's annoying to see mistakes of the past repeated, I personally find it more interesting to see new things not influenced by older ideas. There are things only the inexperienced can imagine; too much experience bakes in assumptions about the world which may not be fundamentally true. Deep knowledge can lead to manipulation and assembly of prefabricated thoughts, rather than a reexamination of the underlying principles behind those thoughts.
This would be fantastic as a sort of "dev/ops live wiki/shell" for small IT departments. I already spend time writing shell scripts and wiki pages so that my coworkers can perform some of my job functions while I'm gone, this takes it to a whole new level where the shell script is the documentation is the dashboard is the README. It's glorious.
This looks cool, but I spent 20 minutes trying to get it running and couldn't make it happen. Maybe the next time it gets posted on HN, the installation process will be a little more mature!
Join the Xiki google group and we'll get your problems fixed! The install has been tested on Lion and the latest Ubuntu and there are some reports of success. A few weeks back we shifted gears to get "gem install xiki" working and improve the install process.
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.
Given that TermKit's last commit was nine months ago, I wouldn't hold my breath waiting. TermKit was a good, thought-provoking design prototype but I don't think it really nailed the next-gen-terminal sweet spot.
Yeah, totally. Someone should do that. I've brainstormed about it with a few XCode savvy friends. It would be super-slick if it were integrated into the Finder windows. So, you could drill into the dirs to get to a Xiki menu, and then drill into the Xiki menus in-place right in the OS.
I just made a Shoes menu (shoesrb.com) yesterday, though it's not checked in yet. Clicking Xiki menus that bring up custom native UI windows seems like it could have a lot of potential, though haven't really explored it. Might be interesting to try a shoes native interface for Xiki menus.
Another possible direction... Xiki has a web interface that you can enable. So you can to http://xiki and navigate menus. It probably wouldn't be too tough to make a native OSX app with an embedded browser that displays it.
well, the integrated database shell looks nice, specially since it should work against different db systems
i think if they limit their focus on have one shell to replace anything that have a shell ... yet offer a better shell experience, they will have a winner
i believe they could be going to too many features so far that those comments comparing it to emacs seem to have a point ...
Among the things that this resembles, I would include Org-mode for Emacs. Org-mode's support for execution of embedded code blocks provides very similar functionality (ships as part of Emacs 24).
http://orgmode.org/manual/Working-With-Source-Code.html
What caused me to decide not to learn org mode is that it expects me to learn many new "keyboard shortcuts". (I am putting the term in quotes because it is not the standard Emacs terminology for the thing.) By "new" I mean "keyboard shortcuts" that are specific to org mode and not present in the rest of Emacs.
This xiki thing on the other hand seems to have only a few new "keyboard shortcuts", and consequently I would be more inclined to adopt it if I gets more traction (hackers who have tried it and like it).
I know a lot of people here like to do everything with the keyboard, but I am not one of them.
I've been aware of Org Mode for a while. It's very slick. Sort of different philosophy but a few similarities (textual syntax for nesting / running commands, etc.).
That looks very promising and I'll surely give it a try. My goal would be to accelerate my current (ba|z)sh workflow to type commands. Sadly, it's not very effective. (Mostly using ctrl-p for last, ctrl-r to find previous command..)
Something interesting I see would be having a .project file in the repository where all the common commands are written. That would be a mix between a cheatsheet and a wiki. For instance, for django, you would have a Database section with some commands. which could dynamically be adapted to the current project. (Database or table names, etc.). Or, if south isn't installed yet, we could see the command to initiate it.. but then, it'll simply be the command to --auto migrate stuff.
Anyhow, really promising and I'm excited to give it a fair try.
The last time I saw this posted I installed it on 2 computers. One was running Mac OS 10.8.1, the other BackTrack 5r2. I have it installed on both and the command xiki-status returns "running" but I have not got it properly implemented in any text editor. I have tried in emacs and vim on both. If anyone gets it to work, especially in vim on Mac (which is very limited), please let me know as the instructions are not helpful, there is no helpful discussion on website and and the only option is to file a bug report. My problems aren't a bug, they are lack of info available.
> I have it installed on both and the command xiki-status returns "running"
That looks promising. Does like "xiki ip" work?
> the instructions are not helpful
Definitely upgrade so you get the latest gem, as the instructions have been updated lately. If you're still seeing errors join the google group (groups.google.com/group/xiki) and we'll get it figured out!
> Not entirely clear what the "cmd-return" is supposed to do. Run a command?
My thought exactly. The website tells me to try the combination, as if advertising a feature, but never ends up telling me what the feature actually is..
[+] [-] roryokane|13 years ago|reply
The “hero unit” at the top should contain a big link to install it (appropriately worded to indicate that it’s just sending you to instructions in a README on GitHub). Another big button link to the screencasts would probably help, since most people won’t understand what Xiki is without them. Alternatively, have a “features” page with a list of features and large, static screenshot demonstrating each of them.
[+] [-] bostonvaulter2|13 years ago|reply
http://xiki.org/screencasts/
[+] [-] mcguire|13 years ago|reply
"Type and double-click Type a word, any word. Then double click on it or type control-return (or command-return). For example type: git, bootstrap, mysql, mongo, rails, node, coffee, js, dom, jquery, svg, ruby code, file paths, url's, shell commands, etc."
I can type and double click on any word in this text box. It doesn't do anything, but I can poke at them all I want. Or, how about this:
"Wiki inspired Everything is editable text. Type commands anywhere. Edit the output. (Vs. typing commands at the bottom, and read-only output.) Intermix menus, headings, bullet points, wherever you want. Xiki == executable wiki."
Why would I want to do any of that? Edit the output of commands?
[+] [-] wheremiah|13 years ago|reply
[+] [-] trogdoro|13 years ago|reply
[+] [-] koglerjs|13 years ago|reply
[deleted]
[+] [-] davidp|13 years ago|reply
The screencast narrator asks a number of intriguing "what if you could XYZ" questions, but it doesn't actually answer them, leaving the listener to come up with useful applications. Well, what if I could do all those things? I would like to have heard more about what higher-level problem(s) these solutions address, and why these are better solutions than what I'm already using. Something motivated the developer(s) to write this, but I can't immediately tell what that motivation was.
[+] [-] vasco|13 years ago|reply
When you first dive into Linux, you learn that you have a thousand different simple commands. And you feel kinda lost. Then you start using them in ways their programmers never imagined. And you chain them with pipes and do some really cool shit.
You do that because nobody told you what they were for, they just were.
[+] [-] trogdoro|13 years ago|reply
I've gotten similar feedback, re imagining what it would be used for. The simplest use case is probably the "shell terminal but better" one. You can narrow down the output of shell commands, and make reusable files with notes as you run stuff (for yourself to use later on, or for other people). You can nest the commands underneath directory paths to avoid having to CD. You can change parts of the paths to re-run the same commands in a parallel dir structure in a different place (even a remote server). You can search command history in a specific dir and re-run commands (vs bash history showing you commands that were run in any dir). You can post any notes you made on the web or email them to people, for others to help others get started using stuff.
Going a bit higher-level, Xiki sort of lets you have "paths" (kind of analogous to url's) for many different things - database records, running commands in specific dirs, running a line of javascript in your browser, changing the style of a div, firing off a button click on a web page given its id, running unit tests, showing runnable (and modifiable) example code for various frameworks, etc. Most people probably agree that having paths for files and web pages is pretty useful. Having paths to other things can be useful for many of the same reasons.
[+] [-] aiurtourist|13 years ago|reply
1) It's too difficult to remember all the tricks to make it useful, and the cost of memorizing tricks that I saw in the first screencast isn't worth the efficiency it provides.
2) It's too difficult for new users to remember the tricks that are supposedly "better." It's a lot like Python vs. Perl -- Perl is a really smart and clever language, but you can type just a few characters more to write Python and it'll be a lot clearer as to what's going on.
The one exception to all of this is the MySQL stuff I saw. The MySQL prompt has sucked for a long, long time, and building SQL queries is something you do iteratively anyway.
All of the above said, I still think this is pretty neat. But I won't use it.
[+] [-] evincarofautumn|13 years ago|reply
As a user of Emacs, Blender, and Perl, I’m probably in the latter camp. And this tool seems like something I might enjoy using. But I don’t think that, as a rule, things should be designed this way unless there’s a very good reason to do so, backed by user research. I would not design a programming language like Perl, for example, because “people who program” will always outnumber “programmers” and it’s best to cater to the majority.
[+] [-] jff|13 years ago|reply
[+] [-] ajuc|13 years ago|reply
It works great, much faster than regular prompt. Shame it's only for oracle db.
[+] [-] JadeNB|13 years ago|reply
Doesn't this same argument lead to the conclusion that new users won't use Perl over Python or --to put it more inflammatorily-- that Python killed Perl? This is surely demonstrably incorrect.
[+] [-] Avshalom|13 years ago|reply
[+] [-] jff|13 years ago|reply
[+] [-] sur|13 years ago|reply
http://doc.cat-v.org/plan_9/4th_edition/papers/rc
[+] [-] jamesbritt|13 years ago|reply
http://news.ycombinator.com/item?id=4483750
http://news.ycombinator.com/item?id=3506613
As with the last time I tried it, it still doesn't work. Crashes right away trying to read from some tmp file.
[+] [-] antihero|13 years ago|reply
But aside from that, this looks fantastic, it'd be interesting to see if more text editors could be ported to it (e.g. Sublime Text 2)
[+] [-] freshhawk|13 years ago|reply
I've got a hobby project that I work on on and off that's similar (although I'm a vim guy no evil mouse clicks) with a heavy org-mode influence. Some of the features you demo in your screencasts are inspired.
I'll be following Xiki closely and probably stealing some of your ideas for my own project.
Good work, I'm glad to see people experimenting with new ideas in modern keyboard based power user interfaces.
[+] [-] hollerith|13 years ago|reply
I tire of trying out software with new bright ideas not informed by a knowledge of the best of the old bright ideas.
EDIT: added the 4 words in italics.
[+] [-] barrkel|13 years ago|reply
[+] [-] vdm|13 years ago|reply
[+] [-] bithive123|13 years ago|reply
[+] [-] mcantor|13 years ago|reply
[+] [-] trogdoro|13 years ago|reply
Join the Xiki google group and we'll get your problems fixed! The install has been tested on Lion and the latest Ubuntu and there are some reports of success. A few weeks back we shifted gears to get "gem install xiki" working and improve the install process.
[+] [-] zobzu|13 years ago|reply
[+] [-] trogdoro|13 years ago|reply
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.
[+] [-] nadinengland|13 years ago|reply
[+] [-] saidajigumi|13 years ago|reply
[+] [-] trogdoro|13 years ago|reply
[+] [-] idonthack|13 years ago|reply
[deleted]
[+] [-] ned|13 years ago|reply
Would it be possible to tap into GUI applications via OSX UI Scripting, and maybe mirroring the app's menus with Wiki menus?
[+] [-] trogdoro|13 years ago|reply
I just made a Shoes menu (shoesrb.com) yesterday, though it's not checked in yet. Clicking Xiki menus that bring up custom native UI windows seems like it could have a lot of potential, though haven't really explored it. Might be interesting to try a shoes native interface for Xiki menus.
Another possible direction... Xiki has a web interface that you can enable. So you can to http://xiki and navigate menus. It probably wouldn't be too tough to make a native OSX app with an embedded browser that displays it.
[+] [-] systems|13 years ago|reply
i think if they limit their focus on have one shell to replace anything that have a shell ... yet offer a better shell experience, they will have a winner
i believe they could be going to too many features so far that those comments comparing it to emacs seem to have a point ...
[+] [-] eschulte|13 years ago|reply
[+] [-] hollerith|13 years ago|reply
This xiki thing on the other hand seems to have only a few new "keyboard shortcuts", and consequently I would be more inclined to adopt it if I gets more traction (hackers who have tried it and like it).
I know a lot of people here like to do everything with the keyboard, but I am not one of them.
[+] [-] trogdoro|13 years ago|reply
[+] [-] d0m|13 years ago|reply
Something interesting I see would be having a .project file in the repository where all the common commands are written. That would be a mix between a cheatsheet and a wiki. For instance, for django, you would have a Database section with some commands. which could dynamically be adapted to the current project. (Database or table names, etc.). Or, if south isn't installed yet, we could see the command to initiate it.. but then, it'll simply be the command to --auto migrate stuff.
Anyhow, really promising and I'm excited to give it a fair try.
[+] [-] Bro_Merch|13 years ago|reply
[+] [-] trogdoro|13 years ago|reply
That looks promising. Does like "xiki ip" work?
> the instructions are not helpful
Definitely upgrade so you get the latest gem, as the instructions have been updated lately. If you're still seeing errors join the google group (groups.google.com/group/xiki) and we'll get it figured out!
[+] [-] slajax|13 years ago|reply
[+] [-] cbsmith|13 years ago|reply
[+] [-] wffurr|13 years ago|reply
Looks like a neat idea. Not entirely clear what the "cmd-return" is supposed to do. Run a command?
[+] [-] tarice|13 years ago|reply
My thought exactly. The website tells me to try the combination, as if advertising a feature, but never ends up telling me what the feature actually is..
[+] [-] gdw2|13 years ago|reply
[+] [-] wladimir|13 years ago|reply
[+] [-] leif|13 years ago|reply
[+] [-] trogdoro|13 years ago|reply