Perspectives (=Home with defined sets of visible contexts)

[dnrce]

Migrated from the original issue at https://www.assembla.com/spaces/tracks-tickets/tickets/1193

Another GTD application has the following very handy feature: you can define perspectives. For tracks, a perspective is a set of contexts that are visible at the moment. It is essentially the home page with some contexts hidden.

The point is that you could be right now at your office and only a subset of the contexts is relevant to you (e.g., office, errand, offline, etc). Hence, you only want to see the contexts you can actually do something for.

I understand that you could can mimik this with defining tags (e.g., an @work tag), however, you would have to always remember when you enter a new action whether it should have that tag.

Tracks would need:

• A configuration table which contexts are visible in which perspective
• A way to select a perspective on the home screen
• A home screen with accesskey for the 'all' perspective, which shows everything. This is essentially the current home screen.

Originally reported by popsch on September 9, 2011 at 15:31:54 (+0200)

[dnrce]

On September 9, 2011 at 15:53:40 (+0200), lrbalt commented:

There is an existing request for this. I'd like the selector to be invisible when you are not using perspectives...

[dnrce]

On September 9, 2011 at 17:21:08 (+0200), cfrankct commented:

While I the see the utility of this option it does feel a bit like feature creep to me. I suppose it depends on how many contexts you have. I currently have 13 and it's not too much trouble to collapse the ones that aren't applicable in a given setting (e.g., when I get to work I collapse 'home, with wife, with kids, errands, I expand office, and leave the others untouched ). Not a big deal for something I do twice a day and probably faster than managing perspectives in my case.

The only drawback is that the closed contexts do take up a lot of screen real estate. So if the collapsed contexts were smaller (presumably using some CSS magic), or better if they moved to the bottom of the task list then I could very well live without perspectives (and to Rainier's point we wouldn't have to worry about confusing new/casual users)

Thoughts?

[dnrce]

On September 9, 2011 at 20:45:00 (+0200), dada.da commented:

+1 on the idea of hiding contexts more effectively. I need 3 contexts at work, and the best solution I've come up with is opening each context in a new browser tab.

I agree with Christian that closing contexts is almost good enough- reloading the page will keep the proper contexts open and hidden. And I agree that closed contexts take up too much space (they also are visually distracting to me and I don't think a smaller typeface would help).

How about a link on the homepage for "toggle closed contexts" - which would set the display property of those closed divs to false? Much like the "toggle notes" does.

With that toggle active, clicking the '-' toggle in a context would make the context invisible. Undoing this action for a context would require reclicking "toggle closed contexts" then clicking on the context you wanted to view.

Seems conceptually simpler than perspectives, for a similar benefit.

[dnrce]

On September 9, 2011 at 21:36:18 (+0200), cfrankct commented:

+1. The toggle is better than either of my initial ideas (making closed contexts smaller or moving them to the bottom)

[dnrce]

On September 9, 2011 at 22:12:20 (+0200), popsch commented:

A simple solution might be just to parse the URL and encode in the URL which contexts should be active. Then you can simply bookmark the perspectives. Something like:

http://localhost:3000/?@inbox&office&errand&call&online

will show the homepage, but only with the contexts @inbox, office, errand, call, and online visible.

This way, tracks will also not need a complex 'handle perspectives' UI.

[dnrce]

On September 9, 2011 at 22:37:58 (+0200), cfrankct commented:

[[file:bV_Yhg2LOr4jPZeJe5cbLr]]: Allows to show / hide any context that has been collapsed in the home view

I went ahead and implemented the toggles (was simpler than parsing URLs, and didn't raise questions about RESTfulness).

Any time a context is collapsed it adds a class 'context_collapsed' to the container, and the 'toggle context' link hides / unhides the collapsed containers.

The patch is pretty localized and should apply fairly cleanly (although I am a bit behind the master branch). No locales done except for English.

It has not been extensively tested, but it WFM.

[dnrce]

On September 9, 2011 at 15:05:38 (+0200), popsch commented:

I get this error when trying to apply the patch:

error: patch failed: config/locales/en.yml:170
error: config/locales/en.yml: patch does not apply

This is trying it on revision e7c0f6c3d2566c19699e9c582327411f2c596614

While I haven't looked at the patch, I still like the URL parsing approach, because it would permit you to easily store multiple perspectives as bookmarks.

[dnrce]

On September 9, 2011 at 19:01:04 (+0200), cfrankct commented:

[[file:bnP_2K2Wur4jZxeJe5cbLr]]: Update patch for popsch

Popsch, thanks for trying this. As for the patch, I'm reluctant to upgrade to HEAD until the recent improvements (bcrypt, bundler, etc) stabilize. I just ran git-diff against your revision number and the resulting patch is way too large and would revert a lot of the recent work. So here's what I can offer, since my changes are limited to three files: a) apply the patch that is attached to this note against your revision. I created it by running git-diff e7c0f6c3d2566c19699e9c582327411f2c596614 app/views/layouts/standard.html.erb public/javascripts/application.js against my tree and hand-deleting the parts that weren't relevant. This will take care of application.js and the layout file. My initial patch may actually have applied cleanly, but in case it didn't use this one. b) add two lines to config/locales/en.yml, right after toggle_notes: Toggle notes add:

toggle_contexts: "Toggle collapsed contexts"
toggle_contexts_title: "Make collapsed contexts (in)visible"

That should do it, but remember that I haven't tested it. (Don't forget to throw out tracks-cached.js if you're running in production.) As for the URL parsing approach, the bookmarks would definitely have some benefit, and if implemented I'd use them, too. However, it feels like a fairly intrusive change and either way, I'd be out of my league trying to implement it. Let me know how you make out, Christian

[dnrce]

On September 9, 2011 at 19:58:31 (+0200), popsch commented:

I applied the patch and added a git branch in my testing fork:

git clone -b toggle_contexts git://github.com/Popsch/tracks.git

I can only see that you show and hide contexts that are hidden by pressing the 'toggle link', right? Is there some other functionality as well?

[dnrce]

On September 9, 2011 at 21:05:56 (+0200), cfrankct commented:

Nope, that's it.

It essentially implements Daniel Allen's suggestion above. In my use case I get to work, collapse the contexts that aren't available there (home, errands, with wife, with kids), expand '@office" and then clean up the visual clutter of the collapsed contexts with the new link. It's a poor man's version of the perspectives you had proposed but it'll work as long as you don't have so many contexts that the constant collapsing / expanding becomes tiresome.

[dnrce]

On September 9, 2011 at 21:43:02 (+0200), cfrankct commented:

One other thought. If you were hell-bent to create a way to store perspectives you could play with the cookies that are created when a context is collapsed. They are called tracks_[username]_context_c[context_number)_collapsed with a value of 'true' when the context is collapsed, and they are deleted when it's expanded.

With a browser cookie manager tool you could load the right set of cookies into your session and you will have restored a perspective. Ugly, not portable, and for anything less than 30 contexts probably more clicks than what I'm doing, but you might be able to automate it if you're so inclined....

[dnrce]

On September 9, 2011 at 23:06:38 (+0200), lrbalt commented:

I just applied the patch from popsch tree. let's see how people like this

[dnrce]

On September 9, 2011 at 06:10:21 (+0200), popsch commented:

Another advantages of encoding the perspective in the URL is the extensibility.

For example, the URL could encode:

• which view is loaded (todos, projects, contexts)
• how are they sorted (date of entry, group by context, due date, number of actions, staleness)
• which contexts are visible (where applicable)

Having this encoded in the URL provides a simple way to configure and store the views. However, I understand that using these ugly URLs bomb the application back to 1994 CGI programming.

[dnrce]

On September 9, 2011 at 20:59:16 (+0200), popsch commented:

The feature doesn't seem to work in the main branch of tracks. It worked in my tree, so I don't know what happened. Has anyone else tried it?

[dnrce]

On September 9, 2011 at 23:34:16 (+0200), lrbalt commented:

I'm using it and it works for me. I've put tests for it and they pass... Are you running production?

[dnrce]

On September 9, 2011 at 05:01:39 (+0200), popsch commented:

It's not working on 4927f39594d0e5a4be97828a2d8050c8ae175f26.

To get this right, this should be the behaviour:

1) Open home screen 2) Press the '-' sign on a context to collapse it 3) Press 'toggle collapsed contexts' and now the collapsed ones should be hidden from the view

I still see them. I'm using firefox 6.0.2

The interesting thing is that it doesn't work on my production database, however, it works on my development database.

Side note: Btw one comment. 'toggle collapsed contexts' should only be visible on the home screen.

[dnrce]

On September 9, 2011 at 06:22:25 (+0200), cfrankct commented:

Did you remember to delete tracks-cached.js when you switched to production?

[dnrce]

On September 9, 2011 at 09:07:34 (+0200), lrbalt commented:

I think Christian is right. When js or css is changed, you should delete the cached versions

[dnrce]

On September 9, 2011 at 21:34:55 (+0200), popsch commented:

Yes, that did the trick. What about deleting tracks-cached.js at the beginning of the ./script/server script?

[dnrce]

On September 9, 2011 at 08:58:58 (+0200), lrbalt commented:

deleting it could be a solution, but with 2.2 when we migrate to rails3.1, all will be different again. Since this only affect people playing with the development tree, I think it is save to let them delete the cached files manually :-)