Mobile-friendly transaction entry? #421
Comments
|
I also thought of implementing something to enter data when on a mobile phone. But I would vastly prefer a native client. What do you think about that? |
|
On Fri, Nov 25, 2016 at 12:28 AM, Dominik Aumayr ***@***.***> wrote:
I also thought of implementing something to enter data when on a mobile
phone. But I would vastly prefer a native client.
What do you think about that?
Android, iOs, Windows Mobile, and various older/niche OSes. All have web
browsers. Native clients would be much more work. Something like kivy could
cover android/iOs, and that'd be almost everything needed. Oh, except for
those old Maemo devices which may prove quite popular among CLI nerds =)
More to the point, though, is that a native client would require the ledger
to be stored on-device. The big advantage to fava (for my own use-case)
would be running it on my home server and being able to enter transactions
on the fly when at the grocery store.
Of course, you could have a native client which communicates with fava, for
example (dunno if beancount has something like that already, doubt it)....
|
|
I have Fava installed at Pythonanywhere and it would be cool if there were mobile-friendly theme. |
|
On Fri, Nov 25, 2016 at 12:42 AM, Igor Fokusov ***@***.***> wrote:
I have Fava installed at Pythonanywhere and it would be cool if there were
mobile-friendly theme.
Nothing a little bootstrap can't fix =) (yes I'm lazy)
|
|
This has been on my mind as well for quite some time. It could be very useful on the desktop too -
OT: We have some mobile support since #321 but I guess that's more geared towards higher-resolution phones. Improvements to the stylesheets to support lower resolutions better are welcome! |
|
I would love a mobile input too especially when traveling
I currently use Google Keep and transcribe manually it's very sad
…On Nov 24, 2016 9:07 AM, "Jakob Schnitzer" ***@***.***> wrote:
This has been on my mind as well for quite some time. It could be very
useful on the desktop too - hledger add-like interactive functionality
would be quite neat.
if there were mobile-friendly theme
OT: We have some mobile support since #321
<#321> but I guess that's more
geared towards higher-resolution phones. Improvements to the stylesheets to
support lower resolutions better are welcome!
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#421 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAUgk5o29_AuRJSfx1SVgNaGtSNCJAsKks5rBeBjgaJpZM4K70Bi>
.
|
|
For support directly in Fava: When viewed on a desktop (big screen), this could be an overlay, and when on a smartphone (small screen) a full page. What should the features be? A form-like input, with dropdowns etc., or just a normal editor with completion, but maybe without all the transactions above (eg. an empty editor)? |
|
+1 for something like hledger-web input with dropdowns |
|
I think the following - just a thought-experiment - would be awesome:
This way I do not have to make my Fava instance publicly accessible, and can input new transactions on-the-go. The public web service could be a generic one, and is accessible to many users (so it does not have to be run by me personally, but can be one public instance for everybody). |
|
On Nov 25, 2016 10:48 PM, "Dominik Aumayr" ***@***.***> wrote:
For support directly in Fava: When viewed on a desktop (big screen), this
could be an overlay, and when on a smartphone (small screen) a full page.
What should the features be? A form-like input, with dropdowns etc., or
just a normal editor with completion, but maybe without all the
transactions above (eg. an empty editor)?
A form input would be ideal. Text input on smartphones is a pain, unless
you have a Bluetooth keyboard handy. Dropdown or auto complete a la hledger
would be good. Having to type in account names within auto complete would
be a drag.
On Nov 25, 2016 10:53 PM, "Dominik Aumayr" ***@***.***> wrote:
I think the following - just a thought-experiment - would be awesome:
Fava syncs your list of accounts and previous payees with a public web
service (I do not want to have my fava-instance exposed to the internet)
Have a native client (iOS is interesting for me), which gets the list of
accounts and previous payees via the web service
Input the transaction via the app, including photos of receipts, etc.
Upload this to the web service
Sync the new information to your local Fava instance
This way I do not have to make my Fava instance publicly accessible, and
can input new transactions on-the-go. The public web service could be a
generic one, and is accessible to many users (so it does not have to be run
by me personally, but can be one public instance for everybody).
Exposing the fava instance to the net is a plus, for me. Primarily because
this allows the user to not just input stuff, but also view the current
state of accounts. For example, how much has been spent in that category
this month.
Also delayed entry increases friction as there's manual additional steps to
undertake between the data entry and actually having the data available.
Of course, security and privacy are also important. One way to kill two
birds with one stone is to have the form on a separate route and only
exposing that route external to your home router or machine. So the only
thing you can do is enter data (but no need for manual upload later, the
data is automatically saved). Proper screening of inputs is important,
obviously.
Public web services are an additional resource (and privacy) hassle I think
may not be worth it.
|
|
I use beancount for my accounting now (switched from ledger-cli), but my family are not command-line people and rely on the web form I made for them in ledgible for adding transactions. I actually really miss the convenience of it myself, too. Please check it out (login demo/demo) -- my mother has been using this for over one year. The main features of this approach are that:
This sounds like a bigger privacy issue, since the web service is getting all your transactions! It would seem to me much more sensible to use TLS and Basic HTTP password protection through eg nginx or httpd - which I am in fact doing already.
Based on my experiences with ledgible, +1 to a web form. It shouldn't be difficult to achieve parity with, then surpass ledgible. I look forward to migrating my family to fava once this is implemented :) |
|
On Sun, Nov 27, 2016 at 10:27 AM, Ankur Kothari ***@***.***> wrote:
1. date entry is usually just one or two clicks, rather than any typing
2. autocompletion can "learn" from your data; eg. if my expenses at
the payee "Costco" frequently go to my Expenses:Grocery account,
Expenses:Grocery should show up first in the autocompletion list for
the 'destination'/debit account. Likewise, if I pay for groceries with my
credit card, that account would show up first for the 'source'/credit
account. (To see this in the demo
<https://lipidity.com/cgi/ledgible/app.py/add>, put the payee as
"Uncle Boons" and see when you type an "e" in either the "to" or "from"
account, the first result is based on previous transactions)
This is precisely why I'm making the proposal.
One thing which would be slightly more work but much nicer would be for
auto fill-in of the first autocomplete when payee is selected. Gnucash does
it this way.
|
|
Thanks @lipidity for the Demo! This looks very useable, and can be optimized for smartphone-browsers as well… so I'm all for implementing something like this. (Forget about the web service-idea, it is stupid.) |
|
Brain-dump of the parts needed:
|
|
I made a first draft how this could look in a Desktop browser:
|
|
From my own development experience, as we're not very information dense
stacked inputs would make more sense. Would directly be usable at all
screen sizes as well.
So at most one value a row rather than multiple elements in the same row.
At most one row per account/amount.
…On Nov 27, 2016 8:19 PM, "Dominik Aumayr" ***@***.***> wrote:
I made a first draft how this could look in a Desktop browser:
[image: screenshot]
<https://cloud.githubusercontent.com/assets/5135450/20648335/13f28a06-b4a4-11e6-84e6-ab840baa0e7b.png>
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#421 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAIR6J88weAbDjUFyFCXi8KuZZNopci5ks5rCXVlgaJpZM4K70Bi>
.
|
|
just a question, it could be good to be able to chose the file where the transaction is added (even if it not seen). |
|
Automatically figuring out which file and within it, which section of a
file a new transaction should be inserted is a solvable problem IMO.
…On Sun, Nov 27, 2016 at 12:04 PM, pfrancois ***@***.***> wrote:
just a question, it could be good to be able to chose the file where the
transaction is added (even if it not seen).
i have two file: one archive , one current. obviously i add only to the
current
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#421 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAUgkyhtP8s6B3sKnn-hJFu0DuKkXz_Vks5rCf6JgaJpZM4K70Bi>
.
|
|
@pfrancois That is a valid feature request - I use multiple files as well! @blais About "automatically": How could an algorithm for figuring out which file and which section look like? |
|
Based on the file currently being viewed, maybe?
…On Mon, Nov 28, 2016 at 3:32 PM, Dominik Aumayr ***@***.***> wrote:
@pfrancois <https://github.com/pfrancois> That is a valid feature request
- I use multiple files as well!
@blais <https://github.com/blais> About "automatically": How could an
algorithm for figuring out which file and which section look like?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#421 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAIR6OEMNBodVLgW5luPyNEV1T5-xDJiks5rCoNzgaJpZM4K70Bi>
.
|
|
One thing that comes to mind for automatically figuring out which file is
to to extract some histograms from each file, e.g. dates, accounts, payees,
etc. You can then use some heuristics to determine where an entry should go
based on e.g. the date (if files are split by year) or accounts involved.
This would probably scale to sections within files as well, if you're using
standard section markers (e.g. org-mode sections)
But personally, I would be fine with just appending all form-based entries
to a separate (staging) file. I prefer to manually go over them anyway, to
make sure everything looks good, especially if I'm not the only one doing
the booking. That way, you can include the staging file from the main file
and still have the entries show up in the reports, but it'll be unambiguous
which entries still need to be checked. An added advantage is that your
other files remain read-only.
…On Mon, Nov 28, 2016 at 3:32 PM, Dominik Aumayr ***@***.***> wrote:
@pfrancois <https://github.com/pfrancois> That is a valid feature request
- I use multiple files as well!
@blais <https://github.com/blais> About "automatically": How could an
algorithm for figuring out which file and which section look like?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#421 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAdWB5KjuwUPjCsHsD5WoE9GYu-6ruGxks5rCoNygaJpZM4K70Bi>
.
--
Best regards,
Daniël Bos
Your government is reading your email. Slow them down with encryption.
My public key: http://goo.gl/gms497 (4096 bit RSA, id EF2D5D91)
Fingerprint : D8D0 9FBE F075 F709 7B52 2F73 326C 2123 EF2D 5D91
|
|
One way would be to define "insert-markers" (special comments, like the one we have right now for where the initial Editor cursor should go), and if there are multiple, provide a dropdown to specify where the transaction should go. This way the process @corani describes could also be implemented, eg. putting the insert-marker in a separate file. |
|
I like the idea of having a specific file for transaction added.
Envoyé de mon iPhone
… Le 28 nov. 2016 à 08:52, Daniel Bos ***@***.***> a écrit :
One thing that comes to mind for automatically figuring out which file is
to to extract some histograms from each file, e.g. dates, accounts, payees,
etc. You can then use some heuristics to determine where an entry should go
based on e.g. the date (if files are split by year) or accounts involved.
This would probably scale to sections within files as well, if you're using
standard section markers (e.g. org-mode sections)
But personally, I would be fine with just appending all form-based entries
to a separate (staging) file. I prefer to manually go over them anyway, to
make sure everything looks good, especially if I'm not the only one doing
the booking. That way, you can include the staging file from the main file
and still have the entries show up in the reports, but it'll be unambiguous
which entries still need to be checked. An added advantage is that your
other files remain read-only.
On Mon, Nov 28, 2016 at 3:32 PM, Dominik Aumayr ***@***.***>
wrote:
> @pfrancois <https://github.com/pfrancois> That is a valid feature request
> - I use multiple files as well!
>
> @blais <https://github.com/blais> About "automatically": How could an
> algorithm for figuring out which file and which section look like?
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub
> <#421 (comment)>, or mute
> the thread
> <https://github.com/notifications/unsubscribe-auth/AAdWB5KjuwUPjCsHsD5WoE9GYu-6ruGxks5rCoNygaJpZM4K70Bi>
> .
>
--
Best regards,
Daniël Bos
Your government is reading your email. Slow them down with encryption.
My public key: http://goo.gl/gms497 (4096 bit RSA, id EF2D5D91)
Fingerprint : D8D0 9FBE F075 F709 7B52 2F73 326C 2123 EF2D 5D91
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
In a mobile browser:
|
|
Looks great =) Regarding more than one account ('split transactions') perhaps it should default to two and have an 'add account' link at the bottom? |
|
Just a quick idea: When we already have a UI for entering transactions, it would be kind of convenient to extend it to the following:
This way parsing a bank-statement would be a straightforward task:
|
yagebu
added
status:resolved
platform:mobile
|
can we integrate firepad to fava? |
Hi, I was testing fava and beancount out (along with hledger and hledger-web against my current gnucash system), and while I love the data display with fava, the transaction entry is really only suitable for computer use (where I'd presumably prefer to use vim/emacs anyway).
hledger-web has a nice form-based transaction input which eases transaction input especially from mobile devices. Please consider something similar. For mobile transaction entry I think the user would just want to enter the description, amount(s), and select accounts from a list (or have search results like in hledger-web).
The text was updated successfully, but these errors were encountered: