OK, I'll take a closer look at this when I next induct someone.

In the meantime, a question: re http://www.diigo.com/profile/edit/basic

* if first name and last name are entered, is there no way of obscuring that information?

I see no padlock icon alongside those fields.

Some colleagues have chosen to

a) have an _obscure_ Diigo ID

and

b) _not_ enter their real names.

Whilst this may be contrary to the social aspect (less likely to find someone by name or ID) we should respect users' wishes.

I might suggest, adding a security option, so that real names can be disclosed only after Diigo friendship has been granted.

Thanks - Graham

> We need userame and email to build the basic user information, for example, user name is used in the URL.

If I'm not mistaken, entry of an e-mail address and a Diigo user name does _not_ prevent the strange behaviour. My recollection is that the _second_ requirement to log in to Diigo occurs immediately or shortly after successful entry of the information required by Diigo.

http://www.diigo.com/annotated/fb02a0776bdc692af1adecce1ffe03eb for a few more highlights, I'll not duplicate them here. Amongst the highlights, I'm

> highly resistant to browser- and platform-specificity

- I'd love Diigo to be as portable as possible.

(Don't be misled by the mass of Apple-related stuff above.)

Adding to the list of thought-provokers:

1) ICeCoffEE - probably my all time #1 favourite software. Not as widely appreciated as it should be. Mr Riley *truly* realises the value of a UI behaviour that's both simple and powerful. (For the Apple history geeks amongst us: ICeCoffEE modelled after ICeTEe, which originated in maybe the early 1990s.)

2) Java. "NO!", I hear someone/many people cry!

Cons:

* not as portable as JavaScript, in that some browsing environments (kiosks etc.) may disallow Java applications/applets; and some OSes may not support a required version of Java.

Pros:

* Java done well is astonishingly good.

EVO may be totally off-topic from Diigo, but the developers seem to be making a very fine job of enabling serious video conferencing/collaboration/screen capture applications - in environments where previously such things were terribly flaky. The aspect of Koala (EVO client) that made me think of Diigo (don't ask me why, exactly) is the screen capture UI. Something about the floatiness.

OK, maybe defocus from Java - but maintain focus on:

* features that are _not_ possible (or not easy) with JavaScript/Diigolet.

If not Java, then:

* what's most portable, most widely applicable - AND powerful?

3) Rounding up point 2:

IF: a percentage of developer effort is ploughed into making Diigolet as portable as possible across a diversity of browsers (I imagine, not trivial)

THEN: could another percentage of developer effort be ploughed into a mutually agreeable method (not necessarily Java) of PORTABLY providing to users of Diigo the extra features that fall beyond the capabilities of Diigolet?

* PROBABLY WITH a consequent reduction in focus on non-portable browser-specific toolbars

("NO!", I hear toolbar users cry; but what's graceful within a toolbar can be equally graceful in other ways, if approached/presented well.)

Thanks to Joel and Maggie and others at Diigo and in the community :)

GP

Disclaimer: I'm not a developer, I know no programming languages. Ruby on Rails developers are probably ROFL.

> The aspect of … that made me think of Diigo (don't ask me why,
> exactly) is … Something about the floatiness.

I suspect that the thought is being firmed up nicely by Joel here:
http://groups.diigo.com/Diigo_HQ/forum/topic/private-public-unread-bookmarks-for-research-7338#5

> * contextual menus?

I began with a false assumption that a focus on excellent use of contextual menus *might* be a way forward (and beyond) the portability barriers that are often intrinsic to browser/platform-specific toolbars.

Now, reading http://www.diigo.com/annotated/fb02a0776bdc692af1adecce1ffe03eb we're reminded that:

* some users prefer to _not_ use contextual menus

and that in turn reminds me that some application/OS developers may restrict or rearrange the ways in which third party options are added to OOTB contextual menus.

(It's true that an excess of contextual menu items can make the menu uninviting.)

The present: we have at least:

1. add bookmarks dialogue in toolbars
2. edit bookmarks dialogue in toolbars
3. contextual changes to such dialogues, depending on whether a group has a dictionary of tags etc.
4. not really enough space in such dialogues
- e.g. multiple word tags lose meaning/distinction through truncation
- other audiences may have different wishes for use of space
5. add/edit bookmarks dialogue(s) in Diigolet
- which doesn't lend itself to all types of page
- the S5 XHTML example is thought-provoking
6. group view of bookmarks
7. personal view of bookmarks
- both 6 and 7 are, to me, like collections of bite-sized 'about' pages
8. the about page, which is about a page
9. the add bookmark page
- which is in some ways, like an about page
- changes to which are envisaged
10. notions of research/report-oriented UIs.

- all of which are fine, but that's much to maintain, much to document, much to test, and so on.

Think about … One Good Page that serves a variety of purposes. Reduce the number of UIs without compromising usability/workflow. It's do-able :)

Of course, you'll never have One Comprehensive Page that Serves All Purposes, but it's food for thought!

> Next phase Diigo - the future

OK, back to the subject line of this topic, and after another weekend of kitten-like playing with the enjoyable ball of wool that is Diigo, it's another opportunity for me to say a huge THANKS! and reduce the whole caboodle to a current use case that's captured neatly in two bullet points.

Those bullet points: visit http://macfusionapp.org/trac/wiki/other then beneath the heading 'Diigo group for Macfusion' click 'gathering, highlighting and minimal annotation'.

> the future

Now: from an group exercise of gathering, I extract annotations.

I copy and paste those annotations. Nice.

A nicer future might be for extracted annotations to take XML form (¿I don't know XML?) and be more intelligently usable by other applications. Such as wikis.

People, argue with me! I'm monopolising! …

Peace,
Graham

> IF: a percentage of developer effort is ploughed into making
> Diigolet as portable as possible across a diversity of browsers (I
> imagine, not trivial)
>
> THEN: could another percentage of developer effort be ploughed into …

Amongst the considerations that may inform future phases:
http://www.diigo.com/annotated/56673c06e8611d741ff4e932ef6a21f2 highlights the complexity of Diigolet.

> * System Services (interapplication communication on Mac OS X)

Services are:

- missing from Firefox :(
- present in Gecko-based Camino :)
- missing from Microsoft Office 2008 :(
- clearly on the roadmap (alebeit with milestone 'OOo Later') for OpenOffice.org :)
- generally, enabled in those applications which have greatest consideration for users' requirements.

If Firefox developers could respect the long-established Services approach to interapplication communication, it would be a huge step in the right direction.

References:
http://caminobrowser.org/
http://developer.apple.com/documentation/Cocoa/Conceptual/SysServices/SysServices.html
http://qa.openoffice.org/issues/show_bug.cgi?id=94394

@ Scott: AFAIK the UI/logic for forums differs from the UI/logic for conversations

Scott Allam wrote:

> adjust the URL of a Bookmark manually

In a different context http://www.diigo.com/annotated/5739fb316e3a5d13001d771419b2818a a key principle is higlighted:

>> annotation/bookmarking is URL-specific

A likely result of a change of URL would be a change of content, with consequent loss of applicability of Diigo highlights.

I do know what you mean, though, Scott. In my early uses of Diigo, I did often wish for the ability to edit a bookmark. Less so these days.

Related and maybe actionable:

1. the Diigo routine at time of bookmarking could be refined to increase the value, the permanence of the bookmark

2. the second URL (the one that's more desirable to you, to us) can be a second bookmark; then instead of

> delete the old one

we should keep both, and Diigo might make it easier to associate the two (but without cluttering/confusing the UIs).

Scott Allam wrote:

> … overlooked … haste, sloppiness … dummy

Such things are normal human behaviours and the best UIs should accommodate, work with human actions :)

Drawing from at least three other threads -

* http://groups.diigo.com/Diigo_HQ/forum/topic/cloud-on-a-time-line-ui-suggestion-7386
* http://groups.diigo.com/Diigo_HQ/forum/topic/an-extensible-conversation-should-more-easily-allow-a-participant-to-invite-a-person-who-is-in-conversation-elsewhere-8668
* http://www.diigo.com/annotated/146bbdb2566175c3dd1f2a39717e8a5b

- and from conversations beyond the forum, here's a ball of wool for the community to play with:

Hint: don't view the six outer parts of the honeycomb as _final destinations_; they are not.

They are, more loosely:

* six _actions_
* any one or more of which may be applied to the focal point (the current bookmark).

I played with the six in different positions. Their current resting places:

* partially reflect the directions in which a right-handed person might move a physical object. Clockwise, from top:

- push to the far side of my desk something that I wish to defer

- freely throw something that's public, as far as my right arm will reach

- groups … 

- friends are behind me (are supportive)

- tuck something private under my left arm

- a list is something I might hold in my left hand whilst I write with my right.

* may assume left-to-right, top-to-bottom language scripts

- would anyone with RTL experience care to comment?

The drag and drop notion is not limited to dragging a single bookmark in a single direction.

Conversely:

* I might drag up to five of the six actions to a single bookmark.

Critically:

* these are the sort of actions that I would happily perform on an iPhone.

Steps beyond the six actions? I don't know. Brainstorm!

The more I think about the seven-part honeycomb, the more I like it. Not just for Diigo.

I imagine a brainstorming exercise involving at least seven people in a room, the seven arranged in a honeycomb, six facing inwards, in arms' reach of each other. If desired end results can not be achieved easily (aim for: two actions) it could be a sign that things are wrong, or merely too complicated.

The exercise might be repeated with the six facing outwards and/or with all seven blindfolded. I don't know what it would achieve but it would certainly be testing of _something_ and moreover, it could be fun :)

(Note to self: c h u b)

Thanks to Scott for adding his voice :)

> … define the problem … develop a UI …

It may take considerable time and effort to reach an agreeable definition of the problem(s).

(A definition is certainly desirable, but I'm not rushing towards one.)

Point-in-time definitions of problems with a system are, to a great degree, based upon people's _preconceptions_ or _limited understanding_ of what a system (or collection of systems) _can_ or _should_ offer. Moving swiftly on to related points:

> … Diigo needs better ways of organizing digital assets. …

I guess that Diigo developers envisage some 'intelligent organisation' (to be done for us, by Diigo).

I'm in favour of reducing the amount of organisation that's required or expected of a person.

However, I don't imagine that pleasing UIs and intelligent organisation can be 'eternal panaceas'. On this subject, I'll create a separate topic.

http://www.diigo.com/about reminds me:

>> developing Diigo to scratch our personal itch - how to discover,
>> process, manage, and share online information more productively and
>> effectively

- and at this point I'd very much like people from Diigo (if they're not too busy with post-brainstorming activities) to offer a few words on:

* their current itches that are most in need of scratching
* aspects that are most disheartening or frustrating (frankness is welcomed)
* the positive aspects of Diigo and its community that continue to be most motivating.

Maybe, a blog post? http://blog.diigo.com/

Joel Liu asked:

> Currently, we focus on thinking about future diigo. What's your
> vision about the next phase diigo?

I'd like to see:

* a roadmap of APIs, complementary to the existing http://www.diigo.com/tools/api

* open source development of toolbars, Diigolet, widget et cetera

* consequent freedom for Diigo developers to (spend less time fixing) spend more time innovating.

> And although you say that Diigo does organize the data for us

More often than not, I find myself working _against_ the organisation!

(That I continue to use Diigo is a testament to what I see as its potential.)

> it only does as well as the amount of discipline and
> dedication you have to inserting your own personal tags. So in the
> end, it STILL falls upon the user's shoulders.

For myself, I find tagging to be a terrible way of organisation, but that's (already in) a separate topic. I recognise that others make very good use of tags.

I do take greater care when tagging for groups -- and for groups that I set up, we do have tag dictionaries -- but the UIs to the dictionary are so obscure that use is rare. And so, the mass of inappropriately tagged content proliferates.

By coincidence earlier today at http://www.diigo.com/annotated/b7f8d4017bcf149ddb2c8fefdcda4981

>> I do often rate things (positively more often than negatively).
>> However: I rarely observe other people's ratings.

- that's not ignorance, simply a recognition that I'm not likely to find what I want _quickly_.

(I might guess the tags and taxonomy that other people apply to a thing in which I'm interested, but guessing takes time.)

Most extensively:

* I use highlights.

My commentary could be better. I tend to hesitate before adding comments and notes, mainly because (a) I don't like repetition and (b) the current UIs to Diigo sometimes require repetition and (c) I'm rarely inclined to figure out where repetition is required!

> There is a UI out there, yet to be developed in my opinion, that
> will allow visual organization of digital assets in a way that
> user's think and naturally work, so that it requires no additional
> steps beyond their natural actions and/or discipline on the users
> part.

+1

> Then a system, such as Diigo, can take that additional metadata and
> analyze and present it back to the user in personalized ways
> depending on their contextual needs.

+1
and in the absence of added/meta data, Diigo should (to a degree, already does) make best use of

* raw data
* semantic information.

PostScript: I don't know what went wrong with that message, I'm editing/correcting as best I can.

Drawing from this topic and from http://www.diigo.com/annotated/a76315d977c02dd62ce62a4daa62b514

> adjust the URL of a Bookmark

> URL variants for an already bookmarked URL

> site manager-defined 'URL synonyms' (for want of a better expression).

> user-defined URL synonyms.

Leading to a random thought, with total disregard for feasibility:

http://www.google.com/search?q=site:apple.com+%22quit+and+rebuild+index%22 results in the familiar Google expression:

"In order to show you the most relevant results, we have omitted some entries very similar to the 1 already displayed.
If you like, you can repeat the search with the omitted results included."

The random thought: we (users of Diigo) sometimes *want* or *require* the similar results - with our annotations.

This is:

* my weekly apology for flooding the forum
* my thanks again to Diigo people!