An alternative GUI, a detailed proposal - GSOC 2011

[Nitish Kumar]

Thank you Christian, I have posted it on the GSoC website.

*    jsled talked about making registers default to auto-split. It does give
a clear picture by showing all the sub-transactions involved right next to
the main transaction which is responsible for invoking all the sub
transactions in the ledger. I think having a consolidated ledger as though
about earlier in the mockup does make it very clear.

So, as soon as the salary is entered into the account through unified
transaction interface, the FPO updates to show the salary amount in the
right side (credits) and the left side(debits) shows all the taxes being
deducted.

*    Talking about the auto-suggest feature. It can help in data entry
speed. But apart from it, since the keywords are registered in a database
(for example, or xml), it can be used to analyse a particular set of item.
What I mean is, currently GnuCash offers an excellent way to generate report
and analyse the activity of a particular "account". By using auto-suggest
keywords we can produce even better in-depth reports of individual items.
What are your thoughts about it?  There are many non-intrusive ways to
collect the keywords.

Regards,
Nitish

On Fri, Apr 1, 2011 at 12:29 PM, Christian Stimming <stimming at tuhh.de>wrote:

> 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
>>
>>
>
>
>