FOSSASIA

.. this post is the continuation of my first draft which you could find it here –http://dolftax.com/2015/04/Designing-a-document-based-collaboration-interface/. I would ask you to go through the first draft before proceeding here, because here I’ve explained only the wireframes which are modified/tweaked, based on the comments on the first draft. This post is structured as /me resolving the comments on my first draft, with the new wireframes and explaining the reasons for modification.

Rooms could be nested

#1 : We could not enforce a topic/subtopic structure because rooms can be deeply nested. Topics and subtopics are all rooms. The users are free to organize the rooms as they wish. They could be topics, they could be something else. At every level, there may be documents and more rooms.

Shared and Private workarea

#2: The basic elements in sTeam are users, groups, rooms and documents. Each group has a workarea connected to it, and each user has a private workroom. Each user is a member of at least one group. So when a user enters the server, there are at least two rooms: the users private workarea, and the workarea of the group, that the user is a member of.

=> Workarea implemented. Under shared workarea, the user will get list of all rooms and documents which he got access to. Under private workarea he would get list of his private documents and rooms, which when shared will move to the shared workarea.

Shared Workarea

Private Workarea

If you notice, you could create a room or document only in your private workarea. When you change permissions for a room/document in your private workarea, it would be pushed to shared workarea automatically.

Permissions are inherited

If a room has rw permissions, then everything inside the room also has rw permissions.

Room view – Level two

Notice the settings icon? Except for the first level, (levels are tracked by the level/stage bar) a user could change room/document attributes with the help ofsettings icon which pops up a window with following options.

The settings option appears only in the levels inner to level 1, because obviously, if the user is in the first level, he is not into any room.

Navigation between rooms

#3: The user can move from room to room. The server keeps track of where the user is, and actions taken (such as creating a document) are relative to the users location. Users can pick up documents (the document is moved from the room, to the user itself), move to another room and drop the documents there.

=> When a document is selected, the copy and paste buttons (look at the above wireframe. buttons next to sort options) are activated. Clicking copy would copy the selected document, and allows you to paste it in any room (where you got access to) until the end of the session. Navigation between rooms could be done by clicking << button. It would popup the navigation sidebar on the right.

Also, if you wish to join any room, use the search bar. It would fetch you the list of rooms. Some rooms will not allow you to access the documents. Click on the user request icon next to room name, which would notify the room admin. When he gives you access, the room/document would be displayed in your shared workarea.

Search Results view

Permission table

#4: A user should be able to insert objects without read and write permissions. One example where this is needed is to send your homework to your teacher. You get permission to insert into the teachers room, but once it’s in there, you can’t read it or write it anymore. It allows far more fine grained permissions than a unix system.

=> A permission button has been added to the ‘onClick of a Room’ view which will be available for the room admin and you.

For an admin, the permission table pop-up would look like the below wireframe (which is self-explanatory)

Minor tweaks

Room sidebar removed

The room attached sidebar options has been moved to the settings popup. A detailed view of a room in any level would look like,

Document View

In document level view, the following options are added,

• Workarea bar
• Delete document option (If access permits)
• Permissions button

Guest view

A guest (who is not logged in) could view the rooms/documents. The view for a guest would look like,

PS: No changes have been made to Create room and Create document pop-ups.

Let me know what you think!

This post is about my way of approach to develop User Interface for a document based collaboration platform. The Ideation is based on Martin’s thoughts, which you can find it here – http://societyserver.org/Topics/sTeam/Interface-elements-for-Document-Management . I would ask you to read the post and be back here.

The structure lives and evolves. and so do the documents. – Martin

Alright, You’re back! The primary goal was not to develop a separate admin panel. Rather the interface adds up extra admin options based on the permissions given to the logged-in user (Maybe, admin).

When I say admin, it means the authorized user who has Read/Write permissions and guest stands for non-authorized user who has only Read permissions.

As quoted, everything here would be documents, of any type (images, plain text, source code, ..) They should be structured into hierarchies. The admin/authorized user should be able to add new room, able to sort by Title/Author/Date, able to Re-arrange the documents, implemented as drag and drop.

Each room should have

• Topic
• Description
• Keywords

and good to have various other attributes which might explain the room well. The admin has a sidebar which options to perform CRUD (Create/Read/Update/Delete) operations on a room. The sidebar is hidden for guest user. The wireframe below is detailed/zoomed view of a room in the above image.

Creating a room asks for Room specific information. If you look at the wireframe below, they are self-explanatory. Permission would be set at this level whether it could be Shared/Private.

On click of a Room/Topic opens up the sub-topics under the room. The listing could be sorted and searched. Communication, being one of the major element for collaboration would be of comments. The admin gets to moderate (Approve/Delete) the comments. At this level, the comments are room-specific.

You should have noted the >> on the right. It opens up a sidebar with Room/Topic listing which then nests into Sub-topic listing. These are the doors which helps the user for hassle-free navigation between rooms.

The sub-topic ( as same as Topic) has description, keywords and various other attributes. The sidebar of options and Add Sub-topic for admins to perform CRUD operations on them. The Sub-topic sidebar would be hidden for guest user.

Considering the hierarchy as a tree, the leaf node be the document. A document could be of any type,

• markup-text (markdown, html, others)
• xml, json, csv
• source-code
• image
• audio
• video
• binary
• object (instance of a script)

Displaying the content of a document in the browser would be based on the type of the document. Anything text based, images and videos are displayed. For other binary files or objects, only metadata is displayed (owner, date of creation etc). And binaries would have a download link. Comments at this level is document specific.

At any level, one should be able to navigate to any room/topic (or) sub-topic with the help of the right sidebar drawer.

The admin has the following options for each document,

• Link
• Copy
• Edit
• Curate (based on document type)

.. whereas guest would have everything else other than Edit.

Link icon pops up a list of Rooms (where the present logged in user has access to) which on click results in adding a link of the document to the respective room. Edit icon opens up the editor only if the document type is of something which could be edited in a browser. A complete document could also be deleted. The interesting part is to distinguish the documents based on the document-type, visually. TheCurate icon pops up the list of documents in the specific room which are of the same document type as the currently viewed one.

A document would be displayed like the below wireframe for a guest user.

Creating a document asks for document specific information and feature for uploading the document. I assumed MIME-Type would be automatically detected. Else, an option could be added. Permission could also be set at document level.

With that said, if you have any suggestions (or) if I’m missing something here, please start the discussion below. Note that these are bare minimum wireframes and therefore would be slightly modified during implementation.

UPDATE: Uh oh! I missed containers. Expect a bit of restructure in my next draft.

Cheers!