In order to make the most used options for date entry easier accessible, add buttons for "today" and "yesterday" in addition to the date picker. These could all be in one line next to each other. "Today" would be selected by default. Additionally there could be a display in the buttons or below the line of buttons showing the actual selected date.

It should be possible to share Kassen, as a start read-only.

For that there could be a share button in the top right of the Kasse detail view, which when clicked gives you a public link in the manner of gruppenkasse.com/#user@host/kassenname

This will look almost exactly like the Kasse detail view, except with nothing editable and without the buttons for »< Kassen«, »share« and »+ New transaction«.

It might happen that you enter an amount but forget to check the checkbox for that participant and thus ignoring the amount entered.

1. We could disable the amount field when the participant is not selected.

2. We could automatically check the participant when the amount field is filled out.

In addition we could point out the difference between selected and not selected more visually. Like making the font gray or changing the background.

Buttons, tabs (#46), clickable list items, even fields, are all difficult to tell apart. Consider a little redesign, probably less "flat".

Here's some inspiration: http://alistapart.com/article/flat-ui-and-forms

• remove click outline
• remove margin below toggle
• add logo in tab overview header

Currently the only way you can discern if a number is positive or negative is the tiny minus in front of the number. Additionally, positive balance should be colored red.

Maybe bold can be used as well, for example when the negative balance reaches -50 or so.

Currently only the dropdown arrow on the right is clickable. Clicking anywhere on the date field should bring up the datepicker though, as you shouldn’t be required to type in the date manually.

i somehow got my gruppenkasse data in a state where grouptabs is only displaying 2 out of 10 tabs ('boxes'). On my remotestorage i only see a 'transactions/' directory, where each item has a timestamp, so it is not clear to me how the gruppenkasse module generates the list of existing tabs? i see no code for this in js/gka/remoteStorageModule.js. How can i debug this, can you give me some pointers?

cheers,
Michiel

when you first connect your remotestorage, it takes about 90 seconds in my case where the widget just says 'connecting'. Even with storage on localhost, so will be even more if you add network latency. it's probably a good idea to use a newer version of the lib and to a privateClient.release('') on startup, and then only retrieve the most recent totals and transactions.

This is with just a few tabs, and data from only the last few months, this would probably get a lot worse if you have two or three years worth of transactions on there.

Please upgrade the app to the latest version as soon as possible! We're rolling out -01 spec support at @5apps today, which means Grouptabs will not work in Chrome anymore, unless it's using a version with the latest critical bugfixes.

P.S.: I actually wanted to send a pull request for this, but unfortunately the dependencies are not in the repo, and not even specified in code (?).

As the menu icon was, also the back arrow icon in the header of the detail view is broken on Firefox OS. Should be a SVG, too.

Currently the date is, say »06.11.2012«. Instead it should be human-readable, like »6 November 2012«.

Maybe even better, and also good for the transaction list: use relative dates, there’s also a great library for that: http:///momentjs.com

Currently there is no way to balance out a tab.

Actually, there is not one right way to get a tab to zero. Still, it would be nice for Grouptabs to offer a feature that proposes a way to it.

One way is to let people with biggest minus pay people with biggest plus. If the plus is smaller you also pay something to the second one, if it is bigger the second person in minus also pays some to the biggest plus and so on.

As a result there could be a payments list like this:

# payoff | Martin -> Tobias (192 €)
Martin: 192, Tobias: -192

# payoff | Gregor -> Vicy (93 €)
Gregor: 93, Vicy: -93

# payoff | Bumi -> Vicy (66 €)
Bumi: 66, Vicy: -66

# payoff | Alex -> Tobias (57 €)
Alex: 57, Tobias: -57

# payoff | Jan -> Emi (50 €)
Jan: 50, Emi: -50

# payoff | Bumi -> Basti (13 €)
Bumi: 13, Basti: -13

# payoff | Jan -> Tobias (6 €)
Jan: 6, Tobias: -6

# payoff | Luke -> Basti (4 €)
Luke: 4, Basti: -4

# payoff | Jan -> Arky (1 €)
Jan: 1, Arky: -1

Thanks @jancborchardt @anagromataf

Would be nice if I could navigate through the application with the default back and forward behavior of the browser. You probably should use routes to implement this.

Currently the transactions are a simple flat list. Transactions are sorted by day and the date is displayed for each transaction, but you don’t really have a visual clue to know when which transaction happened apart from needing to read that date on each transaction.

To fix that, the list should have day separators. Above each day-group, the date should be displayed and have the transactions for that day below. Then we can also remove the date from each individual transaction to give a bit more space to the title.

Would also be cool to have relative dates #3 for that, even if it’s just in parentheses after the number-formatted date.

As in the mockups we discussed, there should be 3 views: Overview, Kasse detail, and add/edit transaction.

The overview has a list of the existing Kassen, with a »+ Neue Kasse« entry at the top, which leads to:

The Kasse detail view has a header with a back button to »< Kassen« and an editable title. Then in the content a list of the people in the Kasse, with their balance (like now), and below a transaction list, hidden behind a »all transactions« dropdown function by default. Above that there’s a button for »+ New transaction« which leads to:

The add/edit view has like now the Title, Date and Participant elements, plus a »Done« button. The »cancel« button is a »< Kasse name« back button in the header. This add/edit view appears when you click »+ New transaction«, as well as when you click an existing transaction.

If, by default, a 'tab' has a group of people, shouldn't those groups of people already be selected when you choose to add a new transaction?

alternatively, have the ability to save groups of people. Most often for me I will select 'band' and have it automatically enter 5 people with their names checked.

In my case, the 'tab' and 'group' are the same, but I could see in other cases they wouldn't be. Ie. 'hackerbeach' would be a tab, but the groups of people could change.

RemoteStorage and Dojo should probably use a package manager like Bower, it's not ideal to have to copy them by hand.

I also don't understand how the build script is supposed to work: build.sh is calling js/util/buildscripts/build.sh, but I have no idea where that file is supposed to come from.

Any idea?

In the tabs view where you choose the tab a click on one of the tab options should choose it and show the tab view instead of waiting for a button click on "ok". "New tab" can be an extra element with an "ok" button.

Currently every transaction and breakdown shows exact currency down to the cent. This makes everything a bit cluttered and also it’s not that important to have it exact down to the cent.

Even if it’s saved in the backend, in the frontend the decimal points should not be displayed.

When editing a transaction there is a red "delete" button at the bottom. It seems to draw attention and might be clicked accidentally.

At least it should have more space towards the "save" button.

Using an old Android and its integrated "Internet" browser the app doesn't start.

On every sync the remote storage sends all transactions as updated date (newValue und oldValue set) although new and old are equal.

remoteStorage.js 0.8.1
Storage provider: 5apps.com

@nilclass @skddc @michielbdejong

getting:

ReferenceError: require is not defined

on

http://grouptabs.michiel.5apps.com/index.dev.html

although afaics i did follow all the build instructions. i would like to find out why my tabs are disappearing but that is a bit hard to debug without building the app myself. any clues why require might be missing?

We need some validation, and probably also disable the save button until there’s a title and participants.

The Dojo-modifications probably messed stuff up a bit. When you tap elements on mobile, there is an overlay/focus thing which is smaller than the whole element.

Next to each Gruppenkasse, your balance could be shown so you know if you are in plus or minus. This is also interesting when there is just one person managing the Kasse because then at least they know their status.

As a start, the app could simply get the name from the first part of the user address.

Currently when you open a new tab, you get the »Add transaction« button as well as the »People/Transactions« toggle.

This toggle at least is useless in the beginning because a new tab has neither people nor transactions. So the toggle should not be shown as long as there are no transactions.

Then we are only left with the button »Add transaction«. Hence when adding a new tab, you should automatically end up at the »Add transaction« screen.

Currently the transactions are not sorted, or rather it appears that newly created entries are sorted to the bottom of the corresponding day.

We have two options:

1. handle it in the background by just generating a timestamp and sorting inside a day by the creation date of a tab
2. introduce a time input field next to the date field

1 has the advantage that it just solves the problem and doesn’t require any additional user input. The drawback though is that it’s sorted by the date when it was put into Grouptabs, not necessarily when the transaction actually happened.

I think that’s ok though. We can always start with 1 and when we notice that it’s confusing add the timepicker on top.

The people/transactions tabs are hard to recognize as such. Also, it's not clear which of the tabs is active.

Especially with the colors in the people tab it doesn't look like the tab belongs to the content below.

By default the amount entered is a negative amount, which means that - for example, if someone receives money, you'd have to put -[amount] which seems counter intuitive.

The way I think about it, when I'm looking at a list of people and amounts. + would mean they received it, and - would mean they paid it. which is the opposite of how it behaves right now.

I always try clicking the username, especially on mobile, because it should be marked up as a label element for the input. Unfortunately it does nothing and you have to hit the tiny input field directly.

When switching between input fields the soft keyboard on mobile (iOS, FirefoxOS) hides and shows instead of just staying active when focus is on any input. Really annoying.

The problem is the Dijit form widgets: https://bugs.dojotoolkit.org/ticket/17540

If you are able to set a "type" for the amounts you enter, this greatly helps later when settling tabs.

Being in CZ but going to DE a lot, I would deal with this quite often.

When looking at the People-list, there currently is no way to know how the balance comes together. You don’t know which transactions a specific person participated in. This leads to not being sure if the balance for a specific person is correct.

We should introduce a per-person breakdown: When tapping a person entry, all the transactions they participated in should be listed much like in the transaction list. In addition, on the bottom right of each entry (on the same line of who paid how much) there should be an either red or green number with the positive or negative balance this transaction resulted in for that person.

There are cases when titles don't break (no spaces for example). Then the whole list (table element) gets too wide and break the layout.

With the native JavaScript floating point numbers there is rounding errors. Use a lib for decimals like https://github.com/shinuza/decimal-js.

Currently you need to type too much when adding a transaction. People need to be manually added by pressing a + button and either getting them from the dropdown or starting to type their name.

Instead, all participants of a tab should be displayed by default (ideally sorted by frequency of having participated in previous tabs so you always have the relevant people up top). Then for each one there should be a checkmark for if they participated in the tab, as well as the money input field.

For adding new people, there should be an empty text field »Add person« at the bottom of the list.

Finishing what we already started with overriding the Dojo style.

We should remove the global white margin and have the elements use full width. Also use an overall lighter style. Have some grey-tones for the less important text elements (in the transaction list) and so on.

Could be due to the slow connection, but shouldn't be happening

"Possibly uncaught error: " [object Array] ".cache["dojo/store/Memory"]/</<.setData@https://grouptabs.5apps.com/js/release/dojo/dojo.js:2
.cache["gka/app"]/</f.init/c/<@https://grouptabs.5apps.com/js/release/dojo/dojo.js:2
notifyConsumer@https://grouptabs.5apps.com/js/remotestorage.min.js:2
resolve/<@https://grouptabs.5apps.com/js/remotestorage.min.js:2

Currently, people are sorted alphabetically by name (I think). More important though is their balance, and where they stand. Probably the people with the most negative balance should be sorted up top, because that’s an indicator for »they need to pay next time«.

In practice there's many situations where one person would pay something for someone else that is not shared or just lends some money.

This can be handled by creating a transaction with two participants, the paying person adding the amount in plus, the receiving person having the amount in minus.

There should be a UI for that.

How about a toggle switch below the date field when entering a transaction saying "shared" or "direct". And when "direct" it switches to two fields for the participants with an arrow between to indicate the direction of payment and a field for amount. Same kind of layout could be used for the transaction list.

Probably using this dropdown interaction element we talked about.

Every previous participant should be in there (sorted descending by how often they participated), so you can just tap to add them. They are added to the list and then a small input box for their payment appears next to them (use input type number to transform the soft keyboard into a number pad, I think). Can be left blank if they didn’t contribute.

The dropdown then moves one down, making it possible to add participant after participant. Already added participants should not appear in the dropdown anymore.

If there’s a new participant, the dropdown also has an input field (like jQuery Chosen) to add a new one.

Currently the currency is hardcoded to Euro (€). Localizing that is useless because you can be in other countries. There’s 2 options as far as I see:

1. Having a setting so you can set the currency for each tab. Default could be Euro or Dollar or whatever.
2. Not showing the currency at all. This is simple but I’m not sure if it’s good because the currency is a nice cue for what to put in.

@xMartin?

At the moment you always have to select the date of the event. By default it should just be set to now / today’s date, as that is most likely the time when you put the event in.

The main usecase for the datepicker is when you want to put in a transaction from yesterday or the day before. Not much further in the past, and definitely not in the future.

The current month-style datepicker isn’t very supportive for that. You can easily misclick, the elements are small etc.

Instead, we should have an iOS-style date-roller widget. Only needs to be one roll (no extra stuff for year or month). Should also show the weekday.

We're transitioning the branding from "Gruppenkasse" to "GroupTabs".

It is clear that Grouptabs will not cover use-cases where there exists a (non-virtual) cash box like a piggy bank or shared bank account. The main idea is to provide an alternative, where every participant pays with own money and a virtual tab is created.

So there's no transaction like withdrawing money or depositing money.

The core kind of transaction, developed from the famous "Badminton" use-case is where one or multiple participants pay for an equally split expense.

Then we said we need a way to settle one person's amount plus we ask each other for money now and then so we came up with a transaction between two participants that is also part of the group tab.

I see a third type where the expense is not equally split. Like in a restaurant. One (or even multiple) participants pays for everybody but every participant owes a different amount to the tab.

Additionally there has been the request to make it possible for one participant to create debts by getting money from a third party. The example was a band that shares expenses but also gets some money for a gig and one person would get that money and add it to the tab. (#47)

That makes four types of transactions so far:

• shared
• direct
• uneven
• earning

The "uneven" case could get a bit complicated UI-wise. But I think it is pretty common (restaurant and "hey, can you bring us something from the supermarket when you go?"). The "earning" is maybe a bit special. On the other hand there can be use-cases where one participant gets money back from a shared security deposit or something which would be the same thing.

What do you think?

I accidently entered someones name wrong, and see no way to correct it without discarding the transactions

we need a favicon!