Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Better buttons #106

Open
cdeil opened this issue Apr 4, 2013 · 4 comments
Open

Better buttons #106

cdeil opened this issue Apr 4, 2013 · 4 comments

Comments

@cdeil
Copy link
Contributor

cdeil commented Apr 4, 2013

Some suggested improvements to the WebOOT buttons:

  1. Separate "toggle" and "action" buttons visually (see description in the last paragraph in the user interface section here for what I mean.
  2. Make them smaller and if possible use the same layout as for the menu at the top.
  3. Grey out or remove buttons that are currently not possible.
  4. One-sentence descriptions in tooltips where its not obvious what they do.
@pwaller
Copy link
Member

pwaller commented Apr 4, 2013

2-4 I agree with, and it's just a matter of finding a suitable way of representing this in the GUI.

3 and 1 (1 especially) need careful thinking about. I think that toggle and action should ultimately not be that different in the important way - that they should both modify the URL.

I envisage using something along the lines of how github handles navigation between files to handle changes in state. The URL should change, ideally, although it doesn't have to cause a page reload. That should blur the distinction between toggle and (currently) url-changing actions.

In addition, I would like to be able to represent some things which are currently represented with with ?query_parmeters in such a way that they can be multitraversed. For example, /!option/logy/true,false/, say. This would allow you to generate plots with options set to multiple values in a way that's currently not possible.

@pwaller
Copy link
Member

pwaller commented Apr 4, 2013

With respect to 3, the difficult part here is determining what should be enabled. I think the solution to this is to make it so that the buttons are automatically generated depending on the resource, or maybe the actions which are available on the resource.

We could hypothetically have a decorator which stacks against an @action which makes it also appear as a button. However, there would be other elements of the presentation which would need more information from elsewhere, so I'm not sure.

@cdeil
Copy link
Contributor Author

cdeil commented Apr 5, 2013

Having the full state in the URL is great, although I can see two downsides of using the URL for everything:

  • if it becomes too long and one has to scroll back and forth it'll take the fun out of editing the URL
  • Some strings don't work, e.g. it's not possible to extend the * wildcard to support shell-type or regex expressions like e.g. file_1[2-5]?.root/Tree_[ABD]/var_A or maybe plot expressions like A + sin(B).

So for some things input fields might be a better UI.

@pwaller
Copy link
Member

pwaller commented Apr 5, 2013

I agree that the URL is ultimately limited in that you can't express arbitrary syntax there. That wasn't my main point in this case. What I meant was that if you're looking at a page, saving the URL at that moment should recreate what you see. This isn't the case right now since the logy state is lost, for example.

The current workaround I envisage for that is to have some sort of aliases file which weboot reads (and maybe writes, if you give it permission to). This would allow arbitrary expressions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants