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 <nit...@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@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
