An alternative GUI, a detailed proposal - GSOC 2011

Fri Apr 1 02:59:54 EDT 2011

Dear Nitish,

the proposal looks very good:
- You explained your motivation sufficiently enough so that we know  
there is a significant personal interest in having this implemented.
- You've explained several consecutive goals, where the first (easy)  
ones will surely be completed within the GSoC timeframe, sufficient  
for the GSoC deliverables. The more complex one may or may not  
completely be implemented during GSoC (but maybe after the summer).
- You've shown your considerable research and thought about your  
approach here, which indicates you will surely reach your first goals  
within GSoC without problems
- Your overall goal is something new, innovative, and exciting. :-)

Thanks a lot. Looking forward to your application inside the GSoC page!

Regards,

Christian

Zitat von Nitish Kumar <nitish at nishmu.com>:

> Key-Implementations: Unified Transaction Dialog, First Person Overview,
> Backlog fetching, Auto-Suggest.
>
> Hello,
>
> I am Nitish. I am interested in developing an alternative GUI for GnuCash.
> Using Qt as the UI framework to integrate and provide rich interactive front
> end for GnuCash core, through CuteCash..
>
> First I would like to list out the goals which I envision from a general
> user's perspective. Then later, I talk about the specific technical
> implementations that I would like to contribute to the project within the
> period of GSOC. Deliverables and Timeline present at the end with a brief
> description on what I have done till now.
>
> Goals:
> =====
> 1) To use the current prototype to integrate existing report views using
> webkit.
> 2) To focus on most used interfaces and enhance them, with a goal to better
> integrate and make it more user friendly.
> 3) Implement a "dynamic and interactive" reporting view, based on an idea of
> First Person Dynamic Reporting.
> 4) Document development activities and project workflow and layout, so as to
> encourage other developers to easily get in and contribute. Also document
> user ideas and suggestions about UI obtained during the period.
> 4) Develop ideas and discuss on how the vast library of Qt can be used to
> rapidly extend the functionality of CuteCash.
>
> Description of Goals:
> ===============
>
> 1)    To create a basic usable version of CuteCash by offering atleast two
> report views. In practice, after creating two report view, it would be
> easier to create more types within project period. But for the sake of
> numerical deliverables, 2 is chosen.
>
> 2)    The next immediate goal is to enhance the front end of data entry
> system for transactions (transaction entry dialog box). Working on the idea
> to provide a central "unified interface" to enter transactions "to and from
> different accounts". Also to provide a fluid and rich experience to enter
> data into fields with three specific areas to improve on: a) to users who
> prefer to use only the keyboard b) to users who prefer use the mouse 3) Make
> possible to enter multiple entries involving multiple accounts through this
> single interface + taking care of point a) and b).
>
> Here is a mockup of the dynamic sort field for Transfer From / To fields, it
> is a rough draft done in a limited time, designed to put out the idea on
> this email:
> http://cdn.nishmu.com/cutecash/mockups/dynamic-search-drop-down.png
>
> The field dynamically matches account name based on first few characters
> entered.
>
> The idea behind this. Currently the option to select From / To is non
> intuitive in transaction dialog. Also in the tab based entering method,
> there is redundancy of category name appearing in front of each account name
> in the From / To fields, making it difficult to select the appropriate
> account name quickly. This can be avoided by a tree based view + dynamic
> search.
>
> Here is a rough mockup of the unified transaction entry dialog:
> http://cdn.nishmu.com/cutecash/mockups/unified-transaction-entry-dialog.png
>
> The "Another" button would allow a user to rapidly feed entries where the
> From - To accounts remain the same. A user can basically cycle through the
> process of 4 tabs and 1 enter key to feed entries one after other. A
> possible issue would be if user needs to enter transactions for different
> dates. This can be solved by including date field inside "Basic Info" group
> at the expense of extra tab key to cycle through. A more better way is to
> offer the choice to user by making it a user preference setting.
>
> 3)    To integrate (with unified transaction dialog created above or / and
> on an independent tab) a new feature called First Person Overview or First
> Person Dynamic Reporting. The idea behind this is that of a human being's
> memory. A person can very well remember what he/she has spent/earned of the
> past few days (like previous 2 days). If that person were to document his
> transactions on a physical book, it would follow a specific pattern most
> similar to General journal reporting or diary writing. The idea is to
> integrate this common human way of visualising and present these entries
> below transaction dialog. So for example a user can enter a transaction and
> its dynamically updated below it in the "First Person Overview" (FPO). This
> view will further allow as a central point to open up various types of
> reports and charts. This would either open up in a new tab or a popup
> depending on the amount of reporting the user wishes to see. Implementation
> of pie charts in pop ups is one of the ideas being thought about first.
> Further, this FPO would implement backlog fetching (like in some irc clients
> like Quassel which fetch previous entries as and when we scroll up). The
> advantage is that there is no pre rendering and the need to generate a
> complete report.
>
> Here is a very rough mockup with details:
> http://cdn.nishmu.com/cutecash/mockups/first-person-overview-details.png
>
> Just plain mockup:
> http://cdn.nishmu.com/cutecash/mockups/first-person-overview.png
>
> The various reports that can be generated at present serve very well for
> some particular purpose. There is a need for generating a report system that
> consolidates the whole activity and provide an interactive way for specific
> entries to be analysed upon (by offering user to click on individual
> items/accounts appearing on FPO. The idea is to integrate the existing solid
> reporting systems (various types of reports), and integrate it into FPO.
>
> 4)    I understand that I would be contributing code to a new undeveloped
> code of a new branch of the project, so I think it would become my
> responsibility to provide and maintain good documentation. This would make
> it easier and encourage other developers to get involved and get started up
> quickly. I believe this can be done using a wiki to maintain the
> developments. Also since new features would be included, a separate wiki of
> end user documentation would be maintained. This can aid in creating Help
> files for users.
>
> 5)    This is only a thinking part of the project to develop further ideas
> for project. The ideas mentioned here would not translate to working
> solutions withing my GSOC period. The vast Qt library would make it possible
> to extend the functionality of CuteCash. Qt Linguist tool for easy
> translations to many languages. This would help non developers to easily
> contribute their translations. Use of Qt Network libray to think about
> implementing a server concept, to act as central processor. It can thus
> communicate with simple applications which are present on mobile devices
> (iphone, android, maemo, meego, etc). They would only act as front end and
> would leave all processing to CuteCash server. Thus greatly increasing the
> types for access methods of accounting systems.
>
> Deliverables:
> ==========
> 1) I provide a solid tested unified data (transaction) entry system for
> CuteCash.
> 2) I provide integration of atleast two report views.
> 3) I enhance the accounts overview and its sub accounts overview on
> different tabs.
> 4) I provide "First Person Overview reporting" with "backlog fetching
> method" with dynamic features to "interact with individual transactions and
> items to pull up detailed reports", which a user has to normally select from
> pull down menu from Tool Bar.
> 5) I provide auto-suggest feature across various field types. Auto-suggest
> data would be independent and stored outside the accounts database.
>
> Timeline:
> =======
> 1) First phase would be to get familiar with the backend C API of GnuCash,
> discuss and get suggestions and ideas on how to get started out using the
> core code. This period would also involve getting familiar with SVN (with my
> experience with Mercurial, it should be easy).
>
> 2) With a better understanding of the codebase, the next step would be on
> designing GUI's for various interfaces. This phase would involve creating
> mockups and getting reviews from end users. Probably by sending the updates
> and mockups via a separate mailing list for CuteCash. This is essential
> since I believe that, the earlier the design issues are sorted out, the
> better.
>
> 3) This part overlaps with the previous step. Basically translating the
> existing GUI, while improving the design of the specific feature: Data entry
> system and Dynamic reporting.
>
>   4) Completely involve the development in the unified data entry system.
> Adopt code-release(to users)-fix cycle. Then work on dynamic reporting based
> on the design decisions done from the research in step 3.
>
>  5) Implement auto-suggest feature for the fields in unified transaction
> entry system. It could be replicated to other areas, but the goal withing
> the GSOC period is to provide working auto-suggest for transaction dialog
> fields.
>
> 6) Development pens down. Most of the documentation would go hand in hand
> with development, since I believe "log things down as you go". But any
> remaining documentation would be done in this phase.
>
> During the project period, for approximately one week there will be minimal
> activity on the project. The lost time will be covered up "in advance" and I
> would make sure to notify about this to the relevant people.
>
> What has been done till now:
> =====================
> I have built and tested the CuteCash code from svn on debian with kde. Got
> comfortable with the c++ UI source files, able to add further controls on
> the QMainWindow. Also checked out the GnuCash gtk UI files to get an insight
> of the application. Meanwhile I am in the process of building the code on
> Windows. But for development I would rather prefer my current unix cmake
> setup. During project period, I plan to release alpha versions of windows
> binaries from time to time, so that a general end user can give suggestions
> on the development process.
>
> What I think about this project:
> ======================
> 1) I am very enthusiastic and excited about this particular project not only
> because of the fun part in coding but also due to a particular personal
> interest and desire. I have analysed a bulk of real world accounting data of
> typical general consumer and have lots of ideas on how to improve the user
> experience with this tool for a general user.
> 2) Stick to it in the long run, to see it does make out to what it set out
> to be, an easy to use solid accounting system.
>
> Thank you for reading. The content presented here is based on what I could
> comprehend, research and analyse. I am sure there are lots of areas to
> improve upon. I would gladly appreciate your suggestions and advice to help
> improve the proposal. I look forward to join an exciting open source
> community, get to know a lot of real world developers out there, and be a
> humble contributor to the community.
>
> Good day!
>
> Regards,
> Nitish
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>