The future: improving Gorilla's user experience

[JonyEpsilon]

This thread is to collect discussion on the vague topic of where Gorilla should go, in terms of the user experience. There follow some quotes from the thread that inspired this one.

[JonyEpsilon]

Jony said on #180:

I agree with you fully in spirit - it is a pain in the **\ to restart Gorilla, and it could definitely be made much better. I'm still a bit uneasy about the current proposal, though, so let me try and write what I think, and figure out why ...

I think the usability of Gorilla could be much better. Using it daily myself, and watching my students use it, I find that it's awkward - when working locally - to have many Gorilla processes running in tmux windows (one for each project). And it can be confusing to remember which port corresponds to which project.

While I do agree with you about whether wrapping a webapp for the sake of having native menus is worthwhile, I think there are arguments for having a native app. I think Gorilla could be a very good environment for complete Clojure beginners, especially with some tutorial material integrated. And my experience with students is that they can find the complexity of running a Leiningen process, opening a tab in a browser etc very confusing, although they do of course get used to it. So, I do think there’s value in thinking about a more application-like experience.

Another problem that I’d like to work on is startup time. At the moment it’s painfully slow to go from wanting to make a quick plot to actually seeing it appear. For one-off quick calculations or plots I still find myself opening Mathematica for just this reason. I don’t think the problem is intrinsic to Clojure itself as an uberjared Clojure app can open much quicker than Gorilla currently does.

All of that said, I think the fact that Gorilla runs as a true web-app, with an easy to run server is one of its greatest features. I love being able to run emacs and gorilla on a remote server, all over an ssh connection, and still have an excellent user experience. I would definitely not want to do anything that takes away this possibility.

So, I’d like to make progress on the usability/desktop/beginner-user front, and on the startup time front, but without sacrificing anything on the server/advanced-user side. I’m not yet sure how to do this, which is - I think - where my reluctance to go along with this suggestion is coming from. I guess my gut feeling is that whatever solution manages to satisfy all of these requirements will necessarily be modular, and it will probably be important to have all of the modules doing just what they should, and no more.

I’m not sure I yet know what I think the lein-gorilla part of the puzzle is really for. It’s key function is to resolve dependencies in the project.clj file and make sure the classpath is right. Whether it should do anything more than that is something I’m hazy on. I say this, because in terms of speeding up startup, minimising dependency on Leiningen would be a good thing. Whether it, or something else should be responsible for helping the user with browser opening/management is very fuzzy in my mind.

That’s quite a long reply for quite a simple topic, but it’s good for me to try and write down what I’m thinking! I’d propose that for the moment we continue to hold off on this feature until I’ve had a chance to think more about how the various bits might fit together, and how the next steps of Gorilla might go.

I’d be very grateful for any thoughts on this matter anyone has :-)

[JonyEpsilon]

Also on #180 I listed a few things that might be worth thinking about:

I've toyed with the idea of having a wrapped-webview shell (like atom-shell or node-webkit) to have Gorilla behave like a true desktop app. I think, though whatever way it goes it would be good to keep the server code just that - server code - and have helper code live elsewhere.

For completeness, the other things that I've toyed with for making Gorilla more user friendly:\

• helper app that monitors running Gorilla instances and has links to open worksheets
• intellij plugin that does much the same
• integrating into atom or lighttable (not easy, sadly)

[JonyEpsilon]

Also worth looking at #132 which is about lighttable integration.

[behrica]

My comments are those:

I like to use the Gorilla repl a lot. I think for doing any type of data analysis, it is the best Clojure options so far. For improving it I would see some areas to think about:

1. How to install additional libraries "easier". Now we need to either use "Alembic" and accept that it does no work in all cases or:
   • stop gorilla
   • change project.clj
   • start gorilla

This is specially a pain on a remote sever, because you need ssh access working. I compare it with RstudioServer. You can get an ready made image of RStudio server for Amazon EC2 and you can just boot and login via browser into RStudio. You never need to see the commandline. (even for installing additional R libraries)

I am not sure, if there is good technical solution for this. The java classpath is rather static and sometimes you need to restart the JVM. So I could only see a bootstrap web application , which allows to configure the "project.clj" somehow and allows restarting of the gorilla JVM via the web applicaition. (Similar in RStudioServer how can restart the R process, if needed)

I would be great if we could make a "ready made" Amazon Ec2 image or a docker image with Gorilla, which is "ready-to-go". We cannot really do that, because a user need to setup the libraries in project.clj himself (on command line).

1. Add more iDE functions to Gorilla ? I am not sure on this.

Comparing with RStudioServer I could see things like:

• multiple windows ?
• an reserved area for showing objects created
• better integrated help pages
• better code editing support (search, replace, refactorings)

But all those are needed for use case "general clojure development" versus "doing data analysis".

Again, I think RStudioServer manged to have both in the same tool. So as a Data Scientist you can do everything in RStudio. (for R)

For Clojure, you need two things. Gorilla + a Clojure IDE (Emacs/Cider, Cursive ..)

[behrica]

For my personal setup, which is having Gorilla on a remote Amazon EC2 machine,

I found a rather "nice" solutions, which consists in:

installing "shell in a box" : https://help.ubuntu.com/community/shellinabox This gives me web based ssh shell, which I use for (re-)starting Gorilla and edit the project.clj file

This means I only need web access to that machine. So we could prepare a docker image, which installs:

• jdk + clojure + leiningen
• shellinabox
• git
• creates a user account
• enables webdav for that user to his directory (for file transfers). Like this article: http://how-to.linuxcareer.com/webdav-server-setup-on-ubuntu-linux

Maybe the shellinabox can be configured to be a restrictive shell, so you can only:

• edit your project.clj
• restart gorilla

So we would have Gorilla-in-a-box.....

This does not need any changes in Gorilla itself, but could improve the user experience a lot. Specially the "quickstart". You would just need to deploy the docker image and it would all work out-of-the box.

What do you think ?

[JonyEpsilon]

Hi @behrica. Thanks for the thoughts!

I think the point about restarting the JVM is a very good one. I think there are quite a few reasons that it would be better to have Gorilla be a "bootstrap web-app" and have it launch an nREPL server that could be restarted: it would go a long way to fixing #111, #125, and #137. It would also make the user experience nicer as you could just have one Gorilla process running, and it could handle multiple projects. Integrating this single-server Gorilla into an atom-shell type native wrapper would then also be much easier.

I've been sketching out a rough idea for how the single-server Gorilla could work. I think I'll try and write up a prototype and see how it feels.

Regarding the gorilla-in-a-box: that sounds like a really nice thing for people wanting to easily run Gorilla remotely. I think in terms of the "quick start" though, a native wrapped app would probably be the best for true beginners (I'm thinking people who've never used Clojure before etc).

[behrica]

Coming back to the restart question.

I think that it is very disruptive, that for adding a library we need to edit the project.clj (outside of Gorilla) and restart Gorilla.

Maybe a way around this, could be to use the alembic library closer integrated into Gorilla. This would mean:

• be able to edit project.clj from inside Gorilla (so dependencies can be added)
• have a gorilla shortcut which executes (alembic.still/load-project)

This could avoid restarts in a lot of cases.

[jonesn]

Hi,

Thanks for the good work!

I'd like to be able to:

• Search across the contents of all notebooks in the project using the webui.
• Create links between notebooks so you can create root pages. Like a light weight wiki.
• Create a table of contents for a notebook based on the markdown headings.

[JonyEpsilon]

Thanks :-) And thanks for the comments. A note, point 2 is already possible, kind of, as you can link to other worksheets with /worksheet.html?filename=. What's annoying is that if you click on the link it starts editing the markdown instead of following it. There are some relevant notes on #194 .

[mattalhonte]

Autosave would be great.

It would also be nice if loading a new worksheet would open it in a new window, rather than overriding your current one.

[chrisjordansquire]

I'm a heavy python user, and my workflow in python for the past few years has been ipython's qtconsole + pycharm. I will load a single data set in qtconsole and start analyzing it, and take the chunks of code I want to run on future datasets and package them into functions in a separate module that I build in pycharm. (I'll periodically reload the module(s) as I add functions using importlib. Similar things are possible in clojure, e.g. http://stackoverflow.com/questions/7658981/how-to-reload-a-clojure-file-in-repl.)

I really, really like that workflow. It's great for writing code that operates on fixed datasets with no available schema. Currently gorilla almost makes it possible to replicate in clojure. The major sticking points are two minor things: (1) Keyboard shortcuts: I use CTRL+A and CRLT+E to move around constantly. It's a major hinderance in Gorilla that I can't do the same thing. I also use up & down arrows to get the previous command(s) rather than move up & down the previous windows. This second one is a major thing for me, and it's one of the two major reasons I don't use ipython's notebooks. It'd be awesome if there was also easy support for moving between matching parenthesis. (2) My browser periodically crashses and I don't want to lose what I had in my running clojure workspace. My browser crashing is just a fact of life. I open many, many tabs, and many of them are for resource intensive web pages. Things such as graphs for services, resource heavy pages of code repositories. So the browser will crash. But I don't want to lose my work when that happens, so I want my clojure REPL running somewhere else.

So, overall I want Gorilla to be closer to the qtconsole (which is basically a shell w/ syntax highlighting & excellent multiline command support) rather than ipython's notebook. (As others have noted, one way of getting this would be to get better clojure support within ipython -- now jupyter, I guess. I'm not sure if much of Gorilla's code could be used to achieve this.)

Regarding (1), I'm tempted to add support for what I want in Gorilla, but I'm not sure where to start. It looks like currently custom keyboard shortcuts can be added via the keymap using Mousetrap, but (1) only for supported shortcuts and (2) I haven't had much success finding a simple javascript command to move the cursor to a specified location in a textbox. Any suggestions?