Gsoc 2010: My vision about desktop client

[mircea]

Hello,

     I am Mircea and I want to build a desktop client.You are probably asking: "why another post about a desktop client?" ... well, because I think that my proposal is different from those before mine. Many proposals means that community will benefit from a better product. I will describe the features I thought about leaving the most technical details for the eventual application.I have added 3 mockups for the app: MainView , EditView and MiniView .
     First thing first: I will develop the application in Actionscript 3 with Flex framework for Adobe AIR Runtime. AIR is a free cross-platform runtime for Flash, HTML and Javascript. It brings the web experince to the desktop enjoying the latter access to resources. Use of a runtime has the advantage that you write the same code for Win, Linux or Mac. Another advantage of Adobe AIR is the auto-update system for its apps.
     First thing I will focus on is user management. Each user will have one or more "identities", this means one Dreamwidth username and optional Facebook and Twitter accounts. Each "identity" will be assign to a tab (as you can see in MainView). There will be a "user info" one (left side in MainView.png) where the user will found: userpic , website ,location , birthday ,status on Twitter and Facebook, other contact info , bio ,interests. This items will be editable.The user will be able to change his userpics.In Facebook zone you will see your current status, inbox, requests and will have a link to your online page.In Twitter zone you will see your status and last tweets. There will be two modes to use the app: online mode and offline with sync. In online mode any action (change on profile , post entry, etc.) will be performed immediatelly , while in sync mode will be added to a queue and all the action will be performed at sync time (when the app will go in online mode). In online mode you will be able to select posts and messages that will be available offline. To make them available will be saved as files on harddisk.
     The second thing I will focus on is enhanced editing. There will be a separation between reading and editing. The main page is dedicated to reading posts and messages. The reading section will have a search (like that on the website).Any editing will be made in a separate window , one for every edit action. You can have as many edit windows as you want. The mockup for it is EditView. Every draft can be saved separately on a file (probably with a xml structure). You could load any previous draft, modify and then save it again or send it. The formatting options will resemble with those available on website.All drafts and saved posts/messages will form the "archive". Its content could be seen on reading section. Before posting something you can see a preview of how it will look on reading section.
     Third thing I have focused on is efficient use of resources. The app can run in "mini-mode"
(mockup is MiniView) without main window or any edit windows. There the user will see the last posts, messages or tweets (summarized , not the all content). The small sized window is cpu-friendly. To add functionality in "mini-mode" will be a command line like interface. Using this interface the user will be able to open main window , open a edit window or save one message/post to "archive". For example a command like: "new post -as Mircea -to dw_dev" will open an edit window with "Post as" and "Post to" input texts completed with "Mircea" and "dw_dev", and "post" selected in type of edit selector. This command line like interface will be found on main page too (as it can be seen on mockup :D). When new stuff appears in "Latest things" zone a customizable sound will be played.
     Another feature will be a theme editor where the user will modify text fonts , background colors or images. I want to use an agile like development method meaning that I will work in sprints (2-3 weeks). After each sprint there will be an usable app ready to get feedback from the mentor and community.
     This is a looong post ... the reason is that I wanted to describe ,as well as I could, my vision about how the desktop client should look like and how should it work.This is only a draft of my proposal so I am eager to hear your opinions about it. Thank you for reading.

Comments

[aedifica]

Would it be possible to use your client for two or more Dreamwidth usernames? Some people have multiple accounts and it would be very convenient to be able to use a single client to update each account without having to sign in separately.

[mircea]

Yes ... an user can have multiple identities. An identity consists of one Dreamwidth username and optional Twitter and Facebook accounts. Every DW username will have a tab. In MainView mockup you can see how should it look like. In that example the app user has 4 DW usernames: mircea, user1,user2,user3.

[cesy]

Would you be able to set "Latest things" to use a particular subscription filter, or to play different sounds for things on different filters?

[mircea]

There will be filter for things that will be shown on "Latest things". The user will be able choose from the following: posts of some user , posts on some communities , messages , tweets or facebook feed.

[cesy]

That's annoying - one of the things I like is being able to use the full functionality of the subscription filters feature. It would be good if the API could be extended so that the client could use your already set-up filters, and then just add tweets and facebook feeds as appropriate.

[mark]

Thanks for posting! The other day denise made a post asking for feedback from the community on a mobile or desktop client:

http://dw-biz.dreamwidth.org/3646.html

You should read through that and see what people are saying. One of the big things that will help us decide which application to accept for working on this project will be which one is closest to what our community wants and needs.

Personally I really like the idea of a Mini Mode. I hate applications that are always large and in the way, so having a way of telling any desktop application to be small and only show me useful information is a good idea.

Something else to consider when you actually submit your Summer of Code application on the Google site will be to also talk about potential risks of the project (things that will be hard to do), how you will approach testing/QA, also it's very important to us to make our clients usable and accessible as much as possible.

Let me know if you have any questions!

[mircea]

The post made by denise was one of my starting points. I have tried to add as much functionality as I could keeping it doable in a 3 months period. My goal is to make a well tested and documented app that can be updated afterward.

For development I will use an agile like method. This means I will work in sprints. After each 2-3 week sprint I will have an usable app ready to be tested. At midterm I want to have first "beta" version ready to be downloaded and tested by the community in order get feedback.

One of things that I think will be hard to do is upload userpics and manage friends and subscriptions.

[mark]

Make sure you codify that in your proposal, then, so that when we look at everybody's proposal we have all the details about what you're thinking for the project.