Usability: a question on different use cases

[JuergeN]

Let's talk about e.g. a web resource. In the current version the User sees the following

  () the composite (www.junes.eu)
   \
    () the URL (www.junes.eu)
     \
      () 1552 (representing the contents of the site in the content panel)

Now, here a see a problem for 2 different use cases. For a "normal" user, this is way to complex. They would not see a need why there is a composite and an URL which are obviously almost the same. All this seems way to complicated!

On the other hand, if you want to better understand DeepaMehta or create your own TopicTypes? it is very important to learn the "construction" of composites and to really see and understand how TopicTypes? are build without _any_ filtering.

I do not think that we can fulfill both requirements in one view. And if we try to compromise between the two, I think we will loose both goals! It will nor be really simple, neither will it be really logical!

So I would suggest to split these two needs e.g. in different workspaces or views. If there was e.g. a special TypeBuilder? or System workspace, it could show me all the details without any compromise. If I am in all other workspaces I just want to see, what I really need to see to use the application.

What do you think?

[Malte]

I completely aggree with your reasoning about the end-user and it is interesting to read that you relate navigation through/revelation of all the ChildTopics? in the Map Panel to the "Type Editor Plugin".

The web resources/trailblaizing use case though could be improved by implementing a custom "Page renderer" (for the composite Web Resource) which does not show/offer the URL topic and any other underlying topic (for revelation) but directly (or optionally) renders the content of the webpage addressed into the page-panel when clicking on "() the composite (www.junes.eu)".

I just filed #512 ("making deepamehta work without the type-builder), as I think it sketches out a quite reasonable step towards filtering of entities/items for potential end-users as described by you here.

Users who want to see everything of DeepaMehta and/or use DM to model the world around them could then just "Activate" the Type Editor Plugin (globally) whenever they need it (and turn it off "Deactivate" it at anytime later).

(While I am assuming one can "Activate" and "Deactivate" a DeepaMehta Plugin while it remains installed, since this is what DMs usage of OSGi would suggest to me.)

So, in general, I completely aggree with you on the necessity to conciously distinct such abstract thought work, like modelling domains, from day-to-day information work, like wanting to read the news.

[Malte]

Though, when I think about it a bit, removing the "Type Editor Plugin" would not hide all the ChildTopics? automatically from end-users. So we probably want another, explicit solution to achieve "preventing users of navigating to (internal) child-topics".

I guess, hiding irrelevant ChildTopics? is up to the application/plugin developer, (see my note above on implementing a new page renderer for browsing) since I (currently) cannot imagine to come to a useful generic solution to solve this issue.

The problem of the solution is: We don't know exactly what qualifies as a "machine room" topic and should be not-navigatable for users, or? I mean the distinction between complex and simple topics doesn't hold very long since creating and editing (just) simple topics will also be of interest for applications/end-users (though this would draw a clear line).

[Malte]

Users perspective

Here's what I think about your initial question:

• The usability (of the webbrowser) can (afaik) already be (significantly) improved with means that the DeepaMehta Webclient already provides.
• The upcoming release will deal (to a small degree, with #431 and type-display in page-panel) with the issue which types will be renderered for e.g. in the Search-Menu and in the Page-Panel.

Both together may already improve the usability for both use-case you mentioned, Web surfin and type building.

What I ask myself after your question is: Do you see type-building, a.k.a. modeling (personal) domains as a (deeply) different (2nd) use-case compared to e.g. surfing the web from within DM? I just ask because I may know some people who don't.

I also see and agree to your point that it might be crucial for end-users in DeepaMehta to be able to explore the existing structures to adapt and/or build completely new structures according to their personal needs, e.g. of personal information management. And I find it interesting that you bring that in relation with type-building, resp. type-editing, because from a user experience perspective this makes very much sense (due to consistency and ease of learning/adaption).

If you ask me: I would say that dealing with abstract concepts is not necessarily part of everydays information work (since me and most other pc-users have already internalized structures provided e.g. from the wimp-paradigm and dont want, or know how to, question the existing structures to then alter them and make applying functions to information easier (for oneself and in the future) in every-day information work. Nonetheless I also have to agree that it is very important while following everyday thoughts to question internalized concepts, but I very much doubt that this is in any ways helpful as, let's say "1st level confrontation", we want to bring to DAUs.

Developers perspective

From the devlopers perspective using the software-platform deepamehta one thing is very clear alerady, before a type-builder should be active for end-users, deepamehta should prevent alteration of my applications domain, just because out of ordinary reasons like maintainability and availability (of a single deepamehta installation). That's another background where #512 comes from. Disabling the complete type-builder and having a working DeepaMehta is already crucial out of 2 use-cases (administrative maintenance and building a lightweight distribution). And for sure, this has merely something to do with the usability question raised here earlier: Do we want to hide certain topics representing application domain/abstract concepts from end-users? How do we identify the important (and thus less-important) types to be shown to (and hidden from) end-users?

[jri]

Sorry, this seems to fuzzy to me