Terminology and User Interface concepts are somewhat confusing

(Warning: large brain-dump ahead, that could probably be split into many issues, but i'm just jotting down notes)

I personally think some of the the terminology and user interface concepts are somewhat confusing, even though I *love* the module(s).

Context UI

First of all, the terminology (or the visual display) of Namespace, Attribute, and Value. I agree that this is less confusing than Space, Key, and Value, but i don't think it's quite there. As a programmer I get this, but what about making this module as easy to use as the views module. For me the metaphor that i figured out after a while was ${namespace}->{attribute} = {value}; (e.g. $space->feature = blog). The way it's displayed visually with all three next to each other gives me the concept of ${namespace}->{attribute}->{value}. You guys are good at user interfaces so you should be able to fix this ;-). Additionally, the examples are misleading. Why would you want to set it to context_ui and section? Why would you want to set it to anything else? Why would you want to set it at all? One last problem with this part of the form: "Section: [ ] (Your site's section.)". That's NOT a section and is yet another piece of terminology, and this one happens to appear nowhere else (except "section info", and it doesn't make sense there either). It should be called "Value", but value has no meaning without namespace and attribute (and of course a clear explanation).
[Edit: issue created for the UI only - http://drupal.org/node/336464]

Another key user interface metaphor that is somewhat confusing for me is the fact that the "set context" areas and the "respond to context" areas are right on top of each other (and the names are confusing too). Set context really is "set the {namespace}'s {attribute} to {value} when the following conditions are met". Does context mean {namespace} + {attribute}? If so, where is this made clear? I thought context meant the individual thing I added via the context UI. The page title says "Edit context: {value}".

Respond to context makes some sense (e.g. set this menu item as active, set this block region as disabled), but again, the word context is overloaded, and I think that it would be better explained (although more verbose) as "Take the following actions when the above conditions are met" which leads me to wonder why you need to specify a namespace, attribute, and value if the only things this can do are take action on the following (I do know, but this is somewhat unclear to someone who wouldn't).
Maybe you could put the context setting and context response things in different tabs?

The "Section Info" part is misnamed. Should be called "variables that are set in page.tpl.php" even though that's too verbose. Not everyone gets page.tpl.php though.

The "Spaces feature" is misplaced. Putting it in "respond to context" makes me think "it's going to provide this feature to spaces when the above conditions are met". In reality though, this actually has nothing to do with context to a user (although I know why in code). This needs to be explained and put somewhere else.

Also, the block settings should go in the "respond to context" section, because they are a response to the context. The blocks are also confusing, using the views metaphor that confuses me of checking some boxes, and then adding them somewhere. What about making it look like the blocks page?

It shows me Disable and Enable tabs, but i have no idea if the item is disabled or enabled, or whether I need to disable or enable it, or anything like that. What will enabling it do when it's already enabled? Disabling it when it's already disabled? You could take an approach like views - don't let editing when disabled. Or have a bar at the top saying "This context is currently disabled. Click to enable". Many options here.
[Edit: Done!]

Something really confusing is on admin/build/context. The table of stuff has a Status column, which as a link do disable. How am I supposed to know if it's disabled or enabled? Shouldn't this go in the operations column ;)?
[Edit: Done!]

Clone screen is great. Maybe a little more visual emphasis on the fact that it's cloning and not normal editing (e.g. not saving will destroy, which could also go for the normal adding).

If there's an export, I expect an import [Edit: I realize there is an import, sorry for not noticing, however I think the thing with the two modes of export still applies.] This shouldn't be too hard to do. I also expect better docs on what "You can use exported contexts in your modules by returning an array of defined contexts in hook_context_define()." means. I figured it out but not everyone can. What about taking the views approach and having two ways, one straight export where you can import into a textbox, and another where you enter your module name and check boxes for which ones to export, and it generates the hook?

That's all my thoughts on context_ui.

Context Prefix

My initial thoughts on admin/build/context/prefix.
"Hmm, this is interesting, I hadn't seen this before, what does it do?"

What's a context prefix? I don't know this myself. I see how it relates to spaces (the path prefix, e.g. {prefix}/{feature}).
The table: Provider makes sense - the thing providing the prefix (that thing should have a name, and the name shoudl be consistent and not be used for anything else).
Prefix method. What's this? It looks like Path is selected by default. That makes sense, it's prefixing using the path. Now, I click on the select box. What's a Keyed Pair? If I select it, it asks me for a key in the Key column, which is hidden by default (maybe the textbox should be appended right after the select box?). What's that? Also, what's a Full Domain? (keep in mind, while I do want to know, this is something that you shouldn't just explain to me, everyone wants to know).

Prefix location settings seems to me like it belongs on a separate tab or somewhere else.

On admin/build/context/prefix/list
Makes some sense. What about providing a clean provider name (e.g. Spaces Site instead of spaces_site), and fixing the column name as above?
Is there any way to edit these? if not, why?

Conclusion

Overall, the module's functionality is wonderful, however there are just a few rough edges that could use a little help ;-).
Also, I really think this module could benefit from the use of the Advanced help module for displaying help pages, which would be very helpful to help people understand what's going on.