Gsoc Application: Desktop Client
Apr. 9th, 2010 06:02 amHello,
This is my application for Google Summer of Code 2010.More about me in my first entry in journal. I want to build a desktop client for Dreamwidth users. I have wrote a post few days ago sketching how the client application should look and work. The things wrote there are still valid. In this post I will point out the features presented there (and add a new one) and I will present a timetable.
I will start by saying why I want to work in open-source and for Dreamwidth. I think that working in a open-source project helps develop your professional skills and soft skills like communication. You cannot only write code you have to interact and make a team with your fellows.
First time I heard about Dreamwidth was as a GSoC mentoring organization. I liked that is an active community.
Client app description
I will develop the app in Actionscript 3 with Flex framework for Adobe AIR Runtime. These will make the client cross-platform running on Win/Mac/Lin. To make app accessibile to everyone I will include Adobe AIR Runtime in the installer. If AIR is not installed the installer will continue configuring it before start installing the client. The installer will be developed in Python ( Linux and Mac come with Python installed).
Once the app is installed any update will be managed from inside the client using Adobe AIR Update framework. This means that the user will not have to download a new version from web , uninstall the old one and install the one; all this will be done by the app. This is an important feature because I can release versions during development to get feedback.
Features: build-in update
User management is an important feature. The app user can login with multiple Dreamwidth usernames. Each DW username paired (or not) with an Facebook or Twitter account forms an "identity". Each "identity" will be displayed in a separate tab in main page . In "user info" zone of main page you will see (and edit) : userpic , location, website , Twitter status or Facebook status. In order to interact with Facebook
I will use Facebook API for Actionscript and twitterscript library for interacting with Twitter. You also be able to see last tweets or Facebook feed on reading space. The app can work in online-mode , when an internet connection is available , or in offline mode when it cannot connect to the server. In offline mode any action made by user(post entry, send message , modify status) will be put in a queue and when the app goes back in online mode all this actions will be completed.
Features: multiple logins , connect with other social communities (Facebook, Twitter) , ability to use it in offline (with syncronization)
Enhanced editing and reading is an another important feature. The reading space in main page will act somehow like the reading page on the website. On top of this space will be a search-box (will resemble with that on home page) for all entries accessible. You will be able to add to Twitter and Facebook feeds. Every reading item can be flagged and saved in "archive". There will be a separation between reading and editing. Every post / tweet will have a link button for comment but clicking it will open a separate edit window. You can open simultaneous multiple edit windows. The user will be able to save drafts in "archive" . "Archive" will consists from flagged items (posts, messages, tweets) and drafts from edit windows. The archive can be shown in reading space. The edit window will have all the features found on the website. You will be able to choose: mood, location , music or comment settings.
Features: multiple drafts simultaneous , saving drafts capability , marking and saving important posts, search capability
Mini-mode and command line like interface are used when the user wants to put the app in background. A mockup is available here . In the "Latest things" zone will be displayed last posts , messages , tweets and Facebook feed according to a filter. To make the mini-mode usable there will be a command line like interface where the user can write commands. I gave an example in previous post .
Sharing music in realtime is a new feature (I did not presented it in previous post). The app will have a mini player (MP3 player) which will share via peer-to-peer technology the currently playing song. A mockup is available here . In the left side is user's playlist , the current song is the top one. In right side is a list of your selected friends and what song are listening in that moment using music sharing capability of desktop client. When you click listen link that song will start playing in your music player. In order to achieve that I will use Adobe Stratus and it's multicast capabilites to send over peer-to-peer technology (using RTMFP protocol , UDP like) the song names and song mp3 content. The mini player will have his own window. If an user has not open the mini player will not be able to share music with his friends.
Features: realtime user interaction
Possible bottlenecks could be circle management and subscription filters handling due to lack or hard to use API. A bottleneck could be also mini player for music sharing especially in testing this feature.
Timetable
I will adopt an agile-like method of developing working in sprints of 2-3 weeks.
Stage #0: 26 april -23 may
Stage #2: 7 june - 28 june
In this period I have my final exams. I will still work for DW but I will dedicate less hours a day
Stage #3 : 28 june - 12 july
Interim stage : 12 july -16 july Giving support to community in using the client and getting first feedback (and maybe bugs)
Stage #4: 17 july - 4 august
Stage #5: 4 august - 16 august
Until midterm I will test each feature separately using use-cases and test-cases. After the release of first beta at midterm I will test the entire application with complex use-cases. In the same time I will ask the community to download the beta and send me feedback (and bugs if this is possible). The same thing will happen with second beta.
This is my application for Google Summer of Code 2010.More about me in my first entry in journal. I want to build a desktop client for Dreamwidth users. I have wrote a post few days ago sketching how the client application should look and work. The things wrote there are still valid. In this post I will point out the features presented there (and add a new one) and I will present a timetable.
I will start by saying why I want to work in open-source and for Dreamwidth. I think that working in a open-source project helps develop your professional skills and soft skills like communication. You cannot only write code you have to interact and make a team with your fellows.
First time I heard about Dreamwidth was as a GSoC mentoring organization. I liked that is an active community.
Client app description
I will develop the app in Actionscript 3 with Flex framework for Adobe AIR Runtime. These will make the client cross-platform running on Win/Mac/Lin. To make app accessibile to everyone I will include Adobe AIR Runtime in the installer. If AIR is not installed the installer will continue configuring it before start installing the client. The installer will be developed in Python ( Linux and Mac come with Python installed).
Once the app is installed any update will be managed from inside the client using Adobe AIR Update framework. This means that the user will not have to download a new version from web , uninstall the old one and install the one; all this will be done by the app. This is an important feature because I can release versions during development to get feedback.
Features: build-in update
User management is an important feature. The app user can login with multiple Dreamwidth usernames. Each DW username paired (or not) with an Facebook or Twitter account forms an "identity". Each "identity" will be displayed in a separate tab in main page . In "user info" zone of main page you will see (and edit) : userpic , location, website , Twitter status or Facebook status. In order to interact with Facebook
I will use Facebook API for Actionscript and twitterscript library for interacting with Twitter. You also be able to see last tweets or Facebook feed on reading space. The app can work in online-mode , when an internet connection is available , or in offline mode when it cannot connect to the server. In offline mode any action made by user(post entry, send message , modify status) will be put in a queue and when the app goes back in online mode all this actions will be completed.
Features: multiple logins , connect with other social communities (Facebook, Twitter) , ability to use it in offline (with syncronization)
Enhanced editing and reading is an another important feature. The reading space in main page will act somehow like the reading page on the website. On top of this space will be a search-box (will resemble with that on home page) for all entries accessible. You will be able to add to Twitter and Facebook feeds. Every reading item can be flagged and saved in "archive". There will be a separation between reading and editing. Every post / tweet will have a link button for comment but clicking it will open a separate edit window. You can open simultaneous multiple edit windows. The user will be able to save drafts in "archive" . "Archive" will consists from flagged items (posts, messages, tweets) and drafts from edit windows. The archive can be shown in reading space. The edit window will have all the features found on the website. You will be able to choose: mood, location , music or comment settings.
Features: multiple drafts simultaneous , saving drafts capability , marking and saving important posts, search capability
Mini-mode and command line like interface are used when the user wants to put the app in background. A mockup is available here . In the "Latest things" zone will be displayed last posts , messages , tweets and Facebook feed according to a filter. To make the mini-mode usable there will be a command line like interface where the user can write commands. I gave an example in previous post .
Sharing music in realtime is a new feature (I did not presented it in previous post). The app will have a mini player (MP3 player) which will share via peer-to-peer technology the currently playing song. A mockup is available here . In the left side is user's playlist , the current song is the top one. In right side is a list of your selected friends and what song are listening in that moment using music sharing capability of desktop client. When you click listen link that song will start playing in your music player. In order to achieve that I will use Adobe Stratus and it's multicast capabilites to send over peer-to-peer technology (using RTMFP protocol , UDP like) the song names and song mp3 content. The mini player will have his own window. If an user has not open the mini player will not be able to share music with his friends.
Features: realtime user interaction
Possible bottlenecks could be circle management and subscription filters handling due to lack or hard to use API. A bottleneck could be also mini player for music sharing especially in testing this feature.
Timetable
I will adopt an agile-like method of developing working in sprints of 2-3 weeks.
Stage #0: 26 april -23 may
- Write a detailed documentation of all the features
- Developing an architecture for the app
- Reading about User Experience and shaping the design for the app
- Getting to know better the community
- Elaborate use-cases and test-cases
- Installers for all platforms
- Login system (integrated with Facebook and Twitter)
- Basic reading capability (posts , tweets , Facebook feed)
- Basic editing capability (posts , tweets , Facebook feed)
Stage #2: 7 june - 28 june
In this period I have my final exams. I will still work for DW but I will dedicate less hours a day
- Adding reading search
- Implementing all edit capabilities
- Implement profile editing
Stage #3 : 28 june - 12 july
- Adding saving drafts capabilities
- Adding flagging (and saving) posts and messages
- Implement offline mode and basic command line like interface
Interim stage : 12 july -16 july Giving support to community in using the client and getting first feedback (and maybe bugs)
Stage #4: 17 july - 4 august
- Bugfixing
- Finalizing command line like interface
- Implementing mini-player for sharing music
Stage #5: 4 august - 16 august
- Testing (with community help especially for mini player)
- Fixing resulting bugs
- Making a wiki and some tutorials about how the app should be used
- Getting all documentation together
Until midterm I will test each feature separately using use-cases and test-cases. After the release of first beta at midterm I will test the entire application with complex use-cases. In the same time I will ask the community to download the beta and send me feedback (and bugs if this is possible). The same thing will happen with second beta.