To GUI or not to GUI?

[neilcollins]

That is the question. Actually the guidance from Brian Lockwood is to go command line for the interface on the Pi - the idea being that this feels a bit more "real" to the kids, I think that's right.

The other GUI will be for reporting - i.e. how long is the Conga, etc. That should be done via a Web page. Doesn't need to be anything sophisticated.

[peterbrittain]

My main concern with a CLI is that it will be clunky. Options would be:

1. A simple hierarchical menu - "press 1 to join a conga, 2 to start your own, ..."
2. A shell like interface that allows you to run simple commands - e.g.
   • start [pasword]
   • join [password]
   • list_members
3. A curses environment, allowing you to reserve part of the screen for messages from the conga and use the rest for the input from the user of the app (which could then be either of the approaches above).

The only one of these that works as a user experience IMO is the last, but it's most of the way to a GUI and so I'm nervous that this is pushing it too far, given that this project is aimed at getting total beginners to start coding.

[lwr20]

How about a shell-like interface and a separate GUI front-end (maybe written in scratch)? Then we get

• the nice user experience for beginners,
• some GUI code that the more advanced users can dig into, modify and understand easily
• and a simple to implement interface to the main conga app.

[peterbrittain]

Might work... I've never used scratch before. Can you create plugins for it to use our conga interface?

[peterbrittain]

Having had a look around the Scratch website, I found this. Looks like we could broadcast new messages to Scratch this way and possibly even take new messages back. That makes for quite an interesting hidden extra IMHO.

[peterbrittain]

Any volunteers to take on the CLI or to create an API to integrate with Scratch?

[ZsigE]

I'm not wild about the idea of using Scratch, at least as the main interface. It's a neat idea in principle, but students would have to have Scratch open and running a completely separate script to the main Conga program - I think this has to be a hidden extra if we're to include it at all.

Curses would work, I think, so long as we keep it simple - I think all we really need from it is to split the screen in two so that incoming messages from the Conga don't scroll your input menu off the screen all the time. The alternative would be to have all the configuration stuff in a simple CLI, and all the dynamically-updating stuff in something like a separate Tk window. I've sketched out a couple of possibilities in this wiki page.

[peterbrittain]

OK - in the recent meeting, we agreed to go CLI and that Phil would run with it.

[peterbrittain]

@ZsigE Thinking about your options:

1. Scratch is a very popular learning tool in early schools - they use it at my primary school for example. While I don't think that it is something that we should use as the main interface, there is a big benefit to allow people to integrate it into a conga as a hidden extra.
2. Looking at your CLI options, I prefer the curses layout.
   • It's a good way to introduce people to more complex CLIs - sepcifically dealing with terminals.
   • I don't think we want to have a mixed mode (e.g. using Tk) interface as it gets too complex to extend.
   • Whatever we do, we're going to need to keep the conga connection running in the background, so exposing the extra data as a live feed is a bonus for users.
   • If you went for the most basic option, you'd have to get the user to poll for new information. Yuck.

[peterbrittain]

Now closing as we have made a decision. Phil has raised a new issue to track the client development.