[davidamis]

The following is my understanding of the hierarchy for actions and containers for actions of the user interface. Do I have it correct? I'm asking for two reasons. First, I want to verify terminology and what can contain what, i.e. a project can't contain a folder. Second, I'm going to write Applescripts, and need to know the constraints the UI places on containers.

Thanks,
David

Inbox
Contains: actions, groups.
Shown in sidebar
Applescript name: inbox tasks (elements of document). In Applescript, contains 'inbox task'

Library
Contains: projects, folders, single-action lists
Shown in sidebar
Applescript name: sections (elements of document)

Section (Applescript only)
Section is an abstraction that can contain folders or projects
Contains:projects, folders, single-action lists
Applescript name: section

Folder
Contains:projects, folders, single-action lists, sections (Applescript only)
Shown in sidebar
Applescript name: folder

Single-Action List AKA Shoebox, SAL
Contains: actions, groups
Shown in sidebar
Applescript name: project, with 'singleton action holder' property set to true

Project
Contains: groups, actions
Shown in sidebar
Applescript name: project

Group AKA Action Group
Note: don't confuse group with grouping
Contains: actions, groups
Not shown in sidebar
Applescript name: task, inbox task (if in the inbox). The tasks element is not empty, i.e. it has subtasks.

Action
Contains: nothing
Not shown in sidebar
Applescript name:task, inbox task (if in the inbox). The tasks element is empty.

[Brian]

That all looks correct to me, but I'm sure someone will find something I missed. ;-)

[Lizard]

When you say "Always shown in sidebar" I'm not sure what you mean. If you Focus on a single project, all other projects are hidden from the sidebar.

[davidamis]

Originally Posted by Lizard

When you say "Always shown in sidebar" I'm not sure what you mean. If you Focus on a single project, all other projects are hidden from the sidebar.

When I started the list, I wasn't sure if you had any control over what does or does not appear in the sidebar. I thought I would have a 'Sometimes shown in sidebar'. I'll update the post and get rid of 'Always' and 'Never'.

You may ask why I thought the user had control of this. An example: if you drag an action from the inbox to the sidebar, it converts it to a project, moves it inside the library or a folder, and causes it to be shown in the sidebar. The third effect is obvious, the second usually makes sense, the first is not obvious. If you drag an inbox item on a project, it just disappears into the project (move, but not shown in sidebar).

I think every user needs to know all of the containers and constraints in the above list to understand why some things can't go into others, or they get converted, and when they will or will not appear in the sidebar.

I'm sure this is covered in other threads, but it does point out a couple of user interface problems with OF: the misuse of direct manipulation, and the unnecessary complexity and limits of the containers.