Customizing appearances of items
Malte Reißig
- improved icon picker
I might be up for doing this.
Regarding the second: When thinking of some first steps on customizing appearances for topics, would be a color-chooser per topic-type, a new-icon-file-uploader per topic-type or an icon-set-picker plugin per topic type. Thinking of getting real with anyone of these choices, the first might be a straight forward dm2-style-hack: coupling topic-type definitions and a color property with a "color chooser" data field renderer. The second one and the third one go hand in hand but i would give the icon-set-picker, enabling the user choose between various icons for one topictype out of a couple of predefined icon-sets priority. What do you think/want?
When thinking of customization of visual representations in general in dm3, i now think that we might need a per user-concept for rendering things as meaningful as possible for individuals, one which is not just based on the type of item represented but also on the preferences of the user, allowing kind of a real visual perspective switch on the same dataset. In a multi-user environment this would simply translate to the functionality that two users are able select individual colors or symbols representing the same conceptual item, in the scope of one deepamehta3 installation.
On Mon, 2010-11-01 at 04:19 -0700, x28 wrote:
This is a pity because it could be a great feature as soon it would
catch up with the usability that was already available in DeepaMehta
2:
- The ability to quickly rename topics titles,
- differently colored topic icons (included out of the box, or the
ability to create them -- at least one highlighted one, like a read
one as towns on a geographic map, is urgently needed again). And the
screaming yellow of the default topic must be overcome.
-- -- --- Maintain your head and share it --- -- - http://blog.deepamehta.de - skype: einseinsnull - jabber: mre at newthinking.de - mail: mre at deepamehta.de - fax: 01803-663388-72229 - tel: 030-42800182 |
Torsten Ziegler
i just want to give my thoughts on this.
First i want to question the role the icons play right now:
to me it looks as if the icon is the main identification of the topic,
as a topic may have no title name but has to have an icon.
This seems to be more motived from a programmers thought
as from a users thought.
I would favour to put more emphasis on the topic name.
Again, coming from the use of freemind i like the concept of
primarily using the topic title name as the screen representation
of the topic. I think this would be most usable if the name is drawn
in a somewaht colored elipsoidal shape that in itself is clickable.
A color chooser would be nice for this.
Then, as further specification of the topic one may add one
or more icons (again like it is done in the actual freemind version)
giving it a more ready to recognize topic theme.
To speak in a more theoretical way:
In deepamehta we try to use multiple relations to one topic
to represent the different shades of meaning a topic has.
In contrast to this the "one icon" identity fixes the topic to one
meaning.
No icon at all would match the deepamehta screen representation
most, as all details on a topic is hidden in the detail pane right now
(this may change in the future with costimzed canvases)
To be able to add multiple icons to one topic would be the first
step to a canvas the renders more topic details on the canvas itself.
Another practical thought:
Right now the icons are used to determine the space a topic
uses on the canvas. With very long title names it happens rather
often that the names overlapp other topics (icons or names)
A new approach to use a bubble shaped area around the whole
topic title and possible icons would allow for a smarter handling
of this problem.
Though it might be difficult to decide in drawing time of the canvas
how big the space is the topic name might use. Especially with user
contributed css (e.g. browser) styles.
Sorry for giving just thoughts right now, but i lack time to give
more substantial code contributions right now.
Torsten
Am 25.11.2010 01:25, schrieb Malte Reißig:
Thanks for the input and sorry for the delay. Here is a thought of mine on the following topic briefly mentioned here before by x28:
- improved icon picker
I might be up for doing this.
Regarding the second: When thinking of some first steps on customizing appearances for topics, would be a color-chooser per topic-type, a new-icon-file-uploader per topic-type or an icon-set-picker plugin per topic type. Thinking of getting real with anyone of these choices, the first might be a straight forward dm2-style-hack: coupling topic-type definitions and a color property with a "color chooser" data field renderer. The second one and the third one go hand in hand but i would give the icon-set-picker, enabling the user choose between various icons for one topictype out of a couple of predefined icon-sets priority. What do you think/want?
When thinking of customization of visual representations in general in dm3, i now think that we might need a per user-concept for rendering things as meaningful as possible for individuals, one which is not just based on the type of item represented but also on the preferences of the user, allowing kind of a real visual perspective switch on the same dataset. In a multi-user environment this would simply translate to the functionality that two users are able select individual colors or symbols representing the same conceptual item, in the scope of one deepamehta3 installation.
-- Torsten Ziegler tor...@ziegi.de
x28
for the valuable theoretical and practical hints.
However, I would still prefer to first have the DM2 advantages
restored. I won't harp on the fact that I invested both time and money
in the great DM2 functionalities that are now damaged by DM3, but
instead I want to try again to explain why they were important.
When Torsten speaks about
I predominantly used. In terms of the
http://www.huffingtonpost.com/stephen-downes/two-kinds-of-knowledge_b_785411.html
two kinds of knowledge, it's more the explicit type of knowledge that
needs representing by meaningful icons (like: person has mobile
number), while for the tacit knowledge "inside the knower" that think
tools cater to, the nebulous grey sphere of DM2 was just ideal, even
more ideal than NO icon and just the name's typeface. The yellow pen
icon just suggests a more concrete, and mostly false, connotation of a
note.
The colored icons I needed were just variants of the grey sphere, but
I was content with colored circles, mainly for the "major node"
function I called a "town" on the map.
Torsten's suggestion of
but please NOT INSTEAD of the existent DM2 pardigm which clearly
distinguished, and hence ideally allowed immediate switching of,
visual overview and verbal detail. Such added functionalities
cluttering the simple usecase UI, should be available upon request at
installation time only.
Similarly, the idea that multiple shades of meanings should be
represented within the NODES on that map rather than by the EDGES,
changes the proven paradigm.
Re: LABEL (sorry that this discussion moved over here).
From the above considerations it follows that labels need to be
changeable in the detail pane. However, I acknowledge Malte's
observation that people might expect the behavior of other UIs and
want to click on the name on the canvas to do a rename. Probably this
"inline-editing" should be possible, too.
But what to click when? Thanks both of you for the practical space/
real-estate concerns. I don't like the ellipsoidal or bubbloid name
shapes of our competitors because they are a waste of real-estate, and
they only serve the decorative purpose of output presentation rather
than thought input rearranging.
I don't mind overlap of labels if it does not impede the selection
click by ambiguity and fine-motorics failure. (In fact, the
unwrappaple names of DM2 were often overlapping.) Also, Clicking on
the name or on the icon can often be hard to distinguish.
I agree with Malte's suggestion that the name should not be selectable
itself at first. But he proposed to first select
> the whole chunk of information (icon/label).
Wouldn't it be easier to require the select only icon first, and then
one could either rename by selecting the name on the canvas or direcly
typing in the detail area.
The most important thing is that neither of these operations must
require any saving, since renaming a fuzzy generic icon is a very
frequent action. For illustration, just go to the example of numbered
text snippets
http://deepamehta.de/wiki/en/Image:SnippetsExample.mp4
that would only gradually be analyzed and named.
Jörg Richter
Thanks a lot for your input!
Let's try to summarize and separate your ideas:
1) Inline editing of topic labels directly on the canvas (possible usage: doubleclick the label to start editing, everything becomes selected, complete editing with ENTER).
2) The topic labels on the canvas (resp. the canvas itself) should *not* be selectable. No text-cursor should appear. (Unintended text selections occur frequently, especially while dragging topics).
3) Topics should be selectable by clicking on their label (not just by clicking on their icon).
4) Colored topic icons. That is, the topic type's settings not only comprise "Icon" but also "Color". Like DM2. So, when no icon is set but a color, all topics of that type would be rendered as genric shapes (e.g. discs) with that color.
5) A different "generic" topic type. The current "Note" type and its visual representation (a pencil) might be too specific. A generic type (e.g. "Topic") and icon (e.g. "fuzzy cloud") might be more appropriate. Like DM2.
6) Adding custom icons. The icon picker (used in the type editor) should allow the user to add hers own icon files.
7) Per-user icon sets in a multi-user DeepaMehta installation (kind of "Themes").
8) Different topic visualization: colored shapes with text label *inside*, optionally enriched by one ore more arbitrary icons (independant from the topic's type). Icons would be user-selected on a per-topic basis.
9) "Save" operation must be implicit. Unsaved changes must never be lost when selecting another topic.
A lot of good ideas are here. Some are rather obvious and easy to implement. Others would require more discussion and deeper conceptualisation. And some are even contradictory with each other. How to proceed best? My suggestion is to make 3 groups:
TO BE INCLUDED IN v0.4.4
Idea 2)
Idea 3)
Idea 4)
Idea 5) to be discussed with idea 5:
=> How should the "generic" type be named (what name appears in the type menu?) and what icon to use for it? We could make it like in DM2: type name "Topic" and a "fuzzy cloud" icon.
=> The reason why the DM3 UI avoids the term "Topic" as a type name: user feedback showed the term "Topic" is unclear because also the more specialized topics (e.g. Person) are called "topics" when talking about the DeepaMehta UI (e.g. "A topic map consists of topics and relations between topics").
=> Should the existing "Note" topic type be part of the DeepaMehta standard installation and what icon would be useful?
TO BE INCLUDED IN v0.4.5
Idea 6)
Idea 9)
TO BE DISCUSSED
Idea 1)
Idea 7)
Idea 8) from my point of view idea 8 is the biggest challenge here as it touches one of the main problems DeepaMehta tries to solve: how to bridge (or even allow a fluent transition) between pure-graphics objects that support the user's visual intelligence and *typed* data-objects that carry a semantic the machine can operate on (e.g. when sending a person an email).
Cheers,
Jörg
x28
I completely agree with your assessment of the ideas 1-2 and 4-9.
> 3) Topics should be selectable by clicking on their label (not just by clicking on their icon)
red rectangle, then clicking on its label will select the label and
show
the text cursor for renaming; All other labels (of other topics) are
not selectable (and their pixels are usable later for rubber band
rectangle selecting, or canvas shifting). This answers also 1).
Another remark for
but labels' renaming in the detail pane would probably be
as easy as renaming them on the canvas (by enter, see 1).
I need the text detail changes primarily for highlighting with
bold. As long as the lines are too long and the text is too
tiny (unless I zoom my browser until the icons are too large),
it's not fun anyway.
> 5) => How should the "generic" type be named?
"Topic", as in DM2. This is consistent with the behavior of many
cognitive map software: Cmap calls their units "concepts". Freemind
"node", Mindmeister "idea", Brain "thought".
The problem that the very disctinct usage scenarios of TYPED topics
(5) or even actionable topics (the challenge discussed with 8) are
covered with the same UI layer, without something like "Advanced"
mode or profile, should be discussed separately as soon as a
usable SIMPLE map scenario like in DM2 is restored.
Matthias
Torsten Ziegler
thnks for clarifying things,
as always this gives room for new comments
Am 28.11.2010 06:05, schrieb J�rg Richter:
> 2) The topic labels on the canvas (resp. the canvas itself) should *not* be selectable. No text-cursor should appear. (Unintended text selections occur frequently, especially while dragging topics).
>
> 3) Topics should be selectable by clicking on their label (not just by clicking on their icon).
for me number 2 would be
if the overelapping labels from other topics do not prevent the
selection by clicking the icon
> 5) A different "generic" topic type. The current "Note" type and its visual representation (a pencil) might be too specific. A generic type (e.g. "Topic") and icon (e.g. "fuzzy cloud") might be more appropriate. Like DM2.
partly my suggestion to remove the icon completely
is due to the obstrusivenes of the "note icon" dm3 uses.
I could go perfectly with the old "generic icon"
> 6) Adding custom icons. The icon picker (used in the type editor) should allow the user to add hers own icon files.
>
> 7) Per-user icon sets in a multi-user DeepaMehta installation (kind of "Themes").
>
> 8) Different topic visualization: colored shapes with text label *inside*, optionally enriched by one ore more arbitrary icons (independant from the topic's type). Icons would be user-selected on a per-topic basis.
these seem to me like things for the future
> 9) "Save" operation must be implicit. Unsaved changes must never be lost when selecting another topic.
the implicit save should be easy to achive
using the focus events. So whenever the user
clicks something the else the detail pane gets
triggered first with a save action.
This should also hapen when the user closes the
browser window/tab without saving first
> Idea 8) from my point of view idea 8 is the biggest challenge here as it touches one of the main problems DeepaMehta tries to solve: how to bridge (or even allow a fluent transition) between pure-graphics objects that support the user's visual intelligence and *typed* data-objects that carry a semantic the machine can operate on (e.g. when sending a person an email)
Isn't this allready part of dm3, the distinction between the detail text
and additional properties that my be assigned to a topic type.
I imagine the topic map then to be able to show or not certain
properties of a topic on the canvas.
property = machine usable knowledge
vs. representation on the canvas
This goes along with the possibility to add properties to
relations see also my next email on a use case for this.
Thanks,
Torsten
--
Torsten Ziegler
tor...@ziegi.de
Torsten Ziegler
it was a draft not yet ready to be sent.
Hi
thanks to J�rg for clarifying things,
as always this gives room for new comments
Am 28.11.2010 06:05, schrieb J�rg Richter:
> 2) The topic labels on the canvas (resp. the canvas itself) should *not* be selectable. No text-cursor should appear. (Unintended text selections occur frequently, especially while dragging topics).
>
> 3) Topics should be selectable by clicking on their label (not just by clicking on their icon).
for me number 2 would be fine,
if the overlapping labels from other topics do not prevent the
selection by clicking the icon (under another label)
> 5) A different "generic" topic type. The current "Note" type and its visual representation (a pencil) might be too specific. A generic type (e.g. "Topic") and icon (e.g. "fuzzy cloud") might be more appropriate. Like DM2.
partly my suggestion to remove the icon completely
is due to the obtrusiveness of the "note icon" dm3 uses.
I could go perfectly with the old "generic icon"
> 6) Adding custom icons. The icon picker (used in the type editor) should allow the user to add hers own icon files.
>
> 7) Per-user icon sets in a multi-user DeepaMehta installation (kind of "Themes").
>
> 8) Different topic visualization: colored shapes with text label *inside*, optionally enriched by one ore more arbitrary icons (independant from the topic's type). Icons would be user-selected on a per-topic basis.
these seem to me like things for the future
> 9) "Save" operation must be implicit. Unsaved changes must never be lost when selecting another topic.
the implicit save should be easy to achieve
using the focus events. So whenever the user
clicks something else the detail pane gets
triggered first with a save action.
This should also happen when the user closes the
browser window/tab without saving first
> Idea 8) from my point of view idea 8 is the biggest challenge here as it touches one of the main problems DeepaMehta tries to solve: how to bridge (or even allow a fluent transition) between pure-graphics objects that support the user's visual intelligence and *typed* data-objects that carry a semantic the machine can operate on (e.g. when sending a person an email)
Isn't this already part of dm, the distinction between the detail text
and additional properties that may be assigned to a topic type.
property = machine usable knowledge
I imagine the topic map then to be able to show certain
properties of a topic on the canvas or not.
This goes along with the possibility to add properties to
relations e.g. direction and label.
I totally agree with Mathias that more knowledge should be
represented in edges than we can do right now.
Another thought of mine is a mechanism to "fix" edges on a map.
As there can be several "meaningful" edges connecting two topics
it might be useful to show them not at the same time to prevent
them to be cluttered.
So if there are multiple edges between two topics the "what relates"
submenu or the corresponding dm3 icons at the bottom of the detail
pane should allow to either show this relation on the active topic
map or jump to another topic map where these edge has been established
and "where it belongs to".
Thanks for your work,