Next phase Diigo - the future - 462 views
started by Graham Perrin on 08 Nov 08
started by Graham Perrin on 08 Nov 08
started by Graham Perrin on 08 Nov 08
started by Graham Perrin on 08 Nov 08
> hard work on perfecting all those little details and staying up
> long hours is being appreciated and quite worth it!
Diigo features and attention to detail are *very* much appreciated!
Joel Liu asked:
> Currently, we focus on thinking about future diigo. What's your
> vision about the next phase diigo?
To provoke thought, in no particular order:
* richness of feature set of Diigo √
* UI diversity/inconsistency - Diigolet, toolbar for Firefox,
toolbar for IE, toolbar for Flock, sidebars
* toolbar complexity in Firefox and/or IE and/or Flock
* Flock
* http://n2.nabble.com/
* http://n2.nabble.com/help/Answer.jtp?id=36
* APIs
* open source
* UI of Apple Preview in Mac OS X 10.5 (Leopard), in particular
the construction of annnotations, and navigation of review of annotations
* dramatic changes to UI of Apple iCal 3.x for Mac OS X 10.5 -
widespread and vocal displeasure, but there's surely a bigger
picture
* System Services (interapplication communication on Mac OS X)
* http://qa.openoffice.org/issues/show_bug.cgi?id=94394
* WebKit
* sidebar
* multi-touch gestures on laptops, mobile and other devices
* Eee PC
* iPhone
* Openmoko
* One Laptop per Child (OLPC)
* contextual menus?
To begin with, I'll do more than place
- a tick against the first point, Diigo :)
- a question mark against the last point, contextual menus.
As thought-provokers, the other points are neither good nor bad. Just there to make us think.
A quote from irc://irc.freenode.net/#webkit
>> WebKit gurus: when I search in Safari and it
>> (a) momentarily zooms the matching texts and
>> (b) casts a shadow on the surroundings:
>> are those gems unique to Safari? Or possible in other
>> WebKit-based applications?
>
> grahamperrin: those are safari features
That's a long list so I expect that key points should spin off into separate topics for manageability.
Best regards
Graham
Postscript: clarified a couple of points, added references.
Second postscript: cursing this forum's mangling of HTML ;)
> 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.
> 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
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.)
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
> 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.
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
It would be powerful and interesting if these labels were customizable by the user. For example, all non-friend diigo users are green, individuals in my "co-worker" friend's list might be purple, in my "consultants" friend list might be blue. If the user is online, you may surround the circle with another bold lined circle to denote they are currently online. You may even be able to define specific alerts that match criteria. For example, if a Diigo user is closely aligned with my interests based on their bookmarks, you might place a label next to their name...
for example: (o) Maggie Tsai {diigo, software, kite flying, horse back riding, etc.}
In this way, individuals can contact Diigo users from other e-mail/network services.
Also, Diigo is missing a golden opportunity for viral, push marketing. If I was able to send a message from the Diigo service to another e-mail service (i.e. Gmail) you could stamp on the bottom of each message, powered by Diigo. listing the benefits of Diigo and a link back to the homepage.
> @ Scott: AFAIK the UI/logic for forums differs from the UI/logic for conversations
Yes, thanks. That would appear to be so. I guess I can understand that, given its a little unfair for people to post a reply and you can pull the rug out from underneath of them but changing your original post. I suppose you run the same risk in a message thread too no?
One thing that does strike me is there are a number of inconsistencies of the UI within Diigo, some of which you have pointed out already. Others are more striking were in one portion of the website you interact in one way and in another a completely different manner.
Thanks for your support!
> 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).
That said, there is an ability to adjust the URL at the point of creation in the original dialog box, but too often that gets overlooked. I do not know if it is a case of haste, sloppiness or a combination of the two, but too often the marked location is not the eventual desired page. I do not think I am alone in this and most likely occurs with newer users.
It might just be easy to say, "hey user, your fault you dummy, you had your chance". But considering the means to adjust the URL in the edit box would be quite trivial, I think it better just to give the user that option.
Interesting idea about grouping related bookmarks together. Something a little less formal and easier to associate than a named Diigo list. I think that one definitely could go on the wish list with some additional thoughts and considerations on how that might be implemented.
> … 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:
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)
What you and others are illustrating with these thoughts about adjustable clouds of personalized emphasis and honeycombs is that the ability to sort and organize your growing list of bookmarks in Diigo is inadequate. There is only a means to compartmentalize your bookmarks into lists and tags, but no way to sort and or filter (other than by tags) your bookmarks by other metadata.
True, grouping digital assets by topicality is a more personal and effective way to store those assets, but that doesn't mean you never want any other way to get at your bookmarks. There isn't even a way to sort/filter by date created, date last visited, alpha-order of bookmark name or URL. At least the search function considers the URL address when performed, but on the whole of it, Diigo needs better ways of organizing digital assets.
> … 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/
> 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.
> 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.
Well, I would say we would ALL like someone (or something) to do the organization for us, because frankly file management is a chore that makes us feel like Librarians. No offense to any librarians out there :-)
And although you say that Diigo does organize the data for us, ironically 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.
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. 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.
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.
- 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.
====== Begin =======
Wow, I like the way you think on this Graham. Its almost a sin, in some circles, to say you do not like tags. If you have it handy, could you point me to the discussion about the pros and cons of tags?
Personally, I think the conventions of tags and others have arose out of desperation and that people can not think of any other way. I actually have some very interesting designs and theories about a visual organizer that would blow traditional tags, lists and filters out of the water, but I am not inclined to share those at this moment.
> 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.
> Currently, we focus on thinking about future diigo. What's your
> vision about the next phase diigo?
Touching briefly upon Joel's question a few weeks ago: I know that concrete ideas are sought, but in honesty I can not (should not) get into 'big picture' mode without understanding a little more about what's under the hood. Knowing how certain objects (if that's what they are) relate to each other, that type of thing. In a week or two I might offer a sketch -- based on guesswork -- for Diigo to comment upon.
OK ... head back now to Joel's more recent plea at
http://groups.diigo.com/Diigo_HQ/forum/topic/what-happened-to-the-read-later-button-5766#15
> * System Services (interapplication communication on Mac OS X)
That one is spun off to
Mac OS X: System Services: provider services in a Diigo application