Skip to content

Category: DougDemo@50

{legacy, from old Doug@50 site} Initial Prototype Spec for Journal

Implemented as an Extension for web browsers (Chrome and Firefox). This will also be done as a mobile app shortly after the web version works.

For clarity: Each audio file is a stream, an Event is a length of time with one or more streams.



The extension will allow the user to record their microphone audio, and computer audio as separate channels (at a single button click). The computer audio is used to help line up/synch with other user’s record and is used to determine what should come together as an ‘event’, something which will necessarily need to become more sophisticated later, with permissions and so on, but for the prototype, all data is open since this will be used to build this project itself and the project itself is open.


Main Screen Tabs:

•  Record Event
•  Stop Recording
•  List of previously used tags to click on to add
•  Space to enter new tags. Tags are always in the form of tag data and tag category, such as ’speaker:Sam’ There will be fields for (at least), these, with will be entered into the system as, fx: ‘topics:data sharing’:
•   Known participants
•   Topics

My Streams
•  List of all events (audio files to start) with option to Rename. Shows status of upload to server and which server is used.
•  Way to add documents to the stream, of any kinds, such as text to do lists, with the option to tag with ‘used at’ time, which will be different from the ‘created’ time in the document itself.

My Contacts
•  Shows a list of all my contacts/friends with icons showing if they are sharing with me.
•  Dialog for adding friends. Responding to friend requisitions should also be here, or via email.

•  Enter username and password
•  Allow sharing of location of recorded data
•  Specify where to store data, with login information for each (Google Docs, Dropbox or Amazon s3/bucket to start)



This is where the user can combine streams into ‘events’ which are an equivalent of EDL (Edit Decision Lists) in video editing – descriptions of what media is to be used and what portions, and when.

The events are edited/packaged by the user and are also imported from other users. This is an area where more user testing will be crucial.

This tab allows the user to search and browse any available timelines. Here the user can play back any audio (not left right, but top to bottom, to allow text to flow with it), video and decide what to play and what to mute, much like how a music editor like GarageBand or Logic handles musical timelines.
Done Recording/Upload

Once done, the website will list the events and users can choose to send this for transcription, with a known company, who will use this interface to do the transcription in an environment which labels each speaker. The invoking will be done to whomever clicks the ‘transcribe button’ at something like $1.25 a min ($0.25 of which is for the time coding).

Users will be notified when the transcription is done and will be able to visit the website to do keyword searches, scroll through the full text and/or the audio, which will be in synch.
The Audio

The audio file will be named after the start time and date, with duration in the title, and ‘a’ at the end. If the system recorded more than one stream, then ‘b’ and so on will be tagged to the other streams. Primary, highest quality stream will always be ‘a’.

The recorded audio is tagged with created time at start of the recording (using correct time through publicly available time-server) as well as completed time, in the document meta. A time stream running along the document, aligning document-time with world-time will be added to the meta-information of the document (the EXIF data), so that any annotations added to the document are also added to the real-world timeline.

This recorded audio goes to a server, in the highest quality possible, and a link is generated. If this is through dropbox this is easy. Probably the same with Amazon or Google storage.

The various feeds from the same time ‘event’ are combined into a multi stream where the person listening can see who is who, by who recorded which stream. This means that transcription can ‘know’ who is who as well.



Proposed flow:

different journal architecture to discuss

Larger version:

Leave a Comment

{legacy, from old Doug@50 site} Core Attributes

Philosophical Foundation

  • Target user is a dedicated knowledge worker interested in becoming ever more intimate and skilled with their information and tools and doing serious work.
  • As such, the system is primarily designed as a responsive desktop system with a large high resolution display, for the fully engaged knowledge professional, not the casual button-clicker. Though it will eventually have a mobile incarnation, that will not be the first focus.
  • The visual interface should be ‘skinnable’ so it can easily be personalized to suit various needs and users.
  • The visual relationships between information units is inherently multidimensional, not 2D or 3D and as such the user needs powerful controls for specifying how the relationships, and which relationships, should be displayed.
  • The project takes as a principle that it is not information which is most fundamental, but interactions, and as such, rich interactivity should be the focus of sustained focus.
  • Multiple views in dynamic ways of Doug information and external information, with suggestions and controls by both author and reader.
  • As this platform evolves, we “power users” will coevolve our practices, conventions, mental models, success criteria, etc. so that we co-inform the Doug evolution as it informs our coevolution.

Infrastructure Requirements

  • An open, extensible document format.
  • Core specifications for rich tagging of time-related events.
  • A focus on robust, rich links.

Collaboration Focus

  • Support collaboration in small teams of individuals who know each other.
  • Support collaboration in very large teams.

• Sharing in meaningful ways.

Co-Evolution of Powerful Systems

• Built as high performance applications for primary use on desktop and mobile devices.

• Specialised code for viewing and interactions, not just off-the-shelf libraries, to ensure performance at least as high performance as modern immersive games. This will include high performance text rendering and manipulation engines.

• Not one monolithic application but a suite, where the APIs and document format is open, so that anyone can build a ‘competing’ application.

• Rich use of emerging interactions, such as aero-connections, gloves, VR, AR, haptic, audio, glance, tongue, ambient and so on.

• Evolving document format which is open for anyone to add features to so that it can support added features in a new piece of software, without having to notify or update legacy applications.

• Hybrid desktop and server model: All users have the (encouraged) option to installing DKR2 on a server as well as their private machine. The server component can be a fully active install or passive, through DropBox and similar services. The distributed server architecture will then provide the same level of server at least, as a commercial single site system, becoming a distributed, non-centrally-controlled network with peer-to-peer redundancy.

Integration With Legacy Systems

• Plugins/Extensions where they can be useful, such as in web browsers and system level, to extract more information when moving information into the DKR system.

• When sharing outside the DKR system, will provide as much meta-data in whatever format is being shared, to make it richer when coming back into a DKR system.

• Web access for supplemental access.

Primary Interactions/Applications

• Reading a rich document in linear form and in alternative forms, including 2D/3D concept map spaces.

• Authoring documents individually and collaboratively.

• Doing research within and outside of Doug.

• Publishing in rich formats within and outside Doug.

• Tracking resources and discussions which are not explicitly in the Doug documents.

Leave a Comment