Project Website | Online Demo | Forum |
It is currently Sat Dec 16, 2017 3:24 am

All times are UTC + 1 hour [ DST ]





Post new topic Reply to topic  [ 16 posts ]  Go to page 1, 2  Next
  Print view Previous topic | Next topic 

Which structuring system should we use?
Poll ended at Wed Oct 31, 2007 1:14 am
Keep it as it is -- two-level category system 0%  0%  [ 0 ]
Categories are cool, but I need a deeper hierarchy 25%  25%  [ 1 ]
Tags are the future 75%  75%  [ 3 ]
Tags are cool, but need an inner hierarchical structure 0%  0%  [ 0 ]
Total votes : 4
Author Message
 Post subject: Which structuring system should we use?
PostPosted: Tue Oct 30, 2007 1:14 am 
Offline
Site Admin
User avatar

Joined: Tue Mar 07, 2006 7:34 pm
Posts: 331
BADGER 1 used a two-level category system for structuring transactions. We may continue this system or change it.

The possible options:
  • Two-level category system: As shown in BADGER 1.
  • Arbitrary-level category system: Categories should be nestable in any depth.
  • Simple tag system: Transactions should have 0 to n tags. Tags themself should have no structure.
  • Hierarchical tag system. Transactions should have 0 to n tags. Tags should be ordered in a hierarchy.

_________________
BADGER finance lead backend developer and site admin


Last edited by enikao on Mon Nov 12, 2007 11:53 pm, edited 1 time in total.

Top
 Profile  
 
 Post subject:
PostPosted: Tue Oct 30, 2007 11:36 am 
Offline
User avatar

Joined: Thu Mar 09, 2006 12:20 am
Posts: 423
Location: Frankfurt a. M., Germany
tags are fun and very web2.0
but this is an accounting system. any accounting system i know has a hierarchical sytem of categories. this is needed because i need to be able to sort transactions into categories that belong to other categories.

example:

i have the category "car" and the sub-categories "insurance" and "gas".


without a hierarchical system i would not be able to analyse my spendings that i am doing for "car" because i would have only one level of tags.

so i vote for option 2: variable-depth hierarchies. i dont see the difference between hierarchical categories and hierarchical tags.

_________________
cheers,
Holger (project coordinator)


Top
 Profile  
 
 Post subject:
PostPosted: Wed Oct 31, 2007 12:43 am 
Offline
Site Admin
User avatar

Joined: Tue Mar 07, 2006 7:34 pm
Posts: 331
holger wrote:
example:

i have the category "car" and the sub-categories "insurance" and "gas".


without a hierarchical system i would not be able to analyse my spendings that i am doing for "car" because i would have only one level of tags.

so i vote for option 2: variable-depth hierarchies. i dont see the difference between hierarchical categories and hierarchical tags.


The main difference I see between tags and categories are hierarchy and multiplicity.

Categories:
Every transaction can have only one category. Relations to other transactions are set explicitly and generally by the category hierarchy.

Tags:
Every transaction can have zero to unlimited tags. Relations to other transactions are set individually by just assigning multiple tags. Tags have either no relation by itself (flat model) or explicitly set by a hierarchy.

In your situation, I would just attach both the tags "car" and "insurance" to one transaction. Then I can analyze all car spendings by just selecting tag "car", all insurance spendings by selecting "insurance" and all car insurance spendings by selecting both tags. This already shows some advantage of the tag system, as there would be no way to have the "car insurance" category both below "car" and "insurance" main categories, so you could either analyze all car related or insurance related spendings easily.

There are also other requirements for multiple structuring entries. For example, I just moved to another place. I bought some new electronics for this place. This would go to my "electronics" category. But I also have a category for "new flat". In a category system, I have to choose. In a tag system, I can have arbitrary number of assignments, at any granularity level.

As seen above, you can simulate a hierarchy by a flat tag system. Therefore, I think a flat tag system is the best way, a hierarchy in the tags would add unnecessary complexity.

If we provide type assist for tags (i. e. if you type the first few characters, BADGER proposes all tags starting with these characters), it is very easy to compose existing tags, for example, to a query.

_________________
BADGER finance lead backend developer and site admin


Top
 Profile  
 
 Post subject:
PostPosted: Wed Oct 31, 2007 9:32 am 
Offline
User avatar

Joined: Thu Mar 09, 2006 12:20 am
Posts: 423
Location: Frankfurt a. M., Germany
you have me fully convinced.

_________________
cheers,
Holger (project coordinator)


Top
 Profile  
 
 Post subject:
PostPosted: Wed Oct 31, 2007 11:08 am 
Offline

Joined: Fri Mar 17, 2006 6:53 pm
Posts: 201
Location: Germany: Mannheim, Kassel
i'll vote as well for tags. i've realized this hierarchical problem with insurance spendings (car and personal).

but the type ahead possibility is indispensable. otherwise we will have problems with spelling differences.

_________________
BADGER finance lead frontend developer


Top
 Profile  
 
 Post subject:
PostPosted: Wed Oct 31, 2007 2:13 pm 
Offline
Site Admin

Joined: Wed Aug 09, 2006 12:59 am
Posts: 131
Location: am Rande des Strombergs
Hi teamplayers,

my favorite way is, do that all as different modules and select as useroption to install

it is as more (more off more) work, but you have peace and the decision the user what he want

Hope you understand my way.

Jürgen


Top
 Profile  
 
 Post subject:
PostPosted: Wed Oct 31, 2007 5:09 pm 
Offline
User avatar

Joined: Thu Mar 09, 2006 12:20 am
Posts: 423
Location: Frankfurt a. M., Germany
juergen wrote:
Hi teamplayers,

my favorite way is, do that all as different modules and select as useroption to install

it is as more (more off more) work, but you have peace and the decision the user what he want

Hope you understand my way.

Jürgen


Honestly, I don't. this discussion is "Tags" against "Categories" and has - at this point - nothing to do with modularization ?

_________________
cheers,
Holger (project coordinator)


Top
 Profile  
 
 Post subject:
PostPosted: Wed Oct 31, 2007 5:38 pm 
Offline
Site Admin

Joined: Wed Aug 09, 2006 12:59 am
Posts: 131
Location: am Rande des Strombergs
Ok ok,
i stay on it, do them twice and let the user say what he need


Top
 Profile  
 
 Post subject:
PostPosted: Wed Oct 31, 2007 5:41 pm 
Offline
User avatar

Joined: Thu Mar 09, 2006 12:20 am
Posts: 423
Location: Frankfurt a. M., Germany
ok understood :lol:
(even though not agreed ;-) )

_________________
cheers,
Holger (project coordinator)


Top
 Profile  
 
 Post subject:
PostPosted: Wed Oct 31, 2007 6:33 pm 
Offline
Site Admin
User avatar

Joined: Tue Mar 07, 2006 7:34 pm
Posts: 331
juergen wrote:
Ok ok,
i stay on it, do them twice and let the user say what he need


I think we have to do a thoughtful decision what to modularize and what to fix.

Theoretically, doing almost everything in a modularized way is very appealing. But if you exaggerate this principle, you add extreme complexity to the system without equivalent gain.

IMHO this question belongs to the part we should fix, as (see above) a category system can be simulated by the tag approach.

_________________
BADGER finance lead backend developer and site admin


Top
 Profile  
 
 Post subject:
PostPosted: Wed Oct 31, 2007 6:44 pm 
Offline
User avatar

Joined: Thu Mar 09, 2006 12:20 am
Posts: 423
Location: Frankfurt a. M., Germany
i am going to take this in german real quick to possibly end the confusion:

hallo leute.

es gibt hier 2 fragen:

1: Modularisieren wir badger, und wenn ja, wie weit?
--> Diese Frage wird in einem anderen Thread diskutiert.

2: Sollten Transaktionen einer Kategorie zugeordnet werden oder sollten sie mit "tags" versehen werden? (bei beidem mit der option, dass hierarchien möglich sind).,

Diese beiden Fragen haben nichts miteinander zu tun, da Kategorisierung bzw. Tagging ein fundamentaler Bestandteil von Badger sind.

Ich habe Jürgens Beitrag so verstanden, dass er gern beides hätte und es den user entscheiden lassen würde. Verstanden, halte ich aber für technisch nicht machbar, da die einteilung der transaktionen eines der fundamentalsten prinzipien von badger darstellen. Wenn wir hier *beides* anbieten können wir große Teile des Badger-Kerns doppelt programmieren.

Ganz klare Aussage: Mit der Diskussion (Modularisierung oder nicht) hat es inhaltlich. garnix zu tun. =)

_________________
cheers,
Holger (project coordinator)


Top
 Profile  
 
 Post subject:
PostPosted: Fri Nov 09, 2007 8:14 pm 
Offline

Joined: Fri Nov 09, 2007 7:08 pm
Posts: 9
How would a transaction tagged 'car' for a model car purchase not be included in a report for car expenses?

_________________
kiss my tulips, not my cheeks


Top
 Profile  
 
 Post subject:
PostPosted: Sat Nov 10, 2007 2:11 am 
Offline
Site Admin
User avatar

Joined: Tue Mar 07, 2006 7:34 pm
Posts: 331
tradeher wrote:
How would a transaction tagged 'car' for a model car purchase not be included in a report for car expenses?


There are two possible solutions:
1) You tag the model car by "ModelCar"
2) We define the tag delimiter by something different from space, so you would tag something like "model car; birthday present". This would require a user-definable tag delimiter, which shouldn't be hard to implement.

_________________
BADGER finance lead backend developer and site admin


Top
 Profile  
 
 Post subject:
PostPosted: Sat Nov 10, 2007 1:27 pm 
Offline
User avatar

Joined: Thu Mar 09, 2006 12:20 am
Posts: 423
Location: Frankfurt a. M., Germany
tradeher wrote:
How would a transaction tagged 'car' for a model car purchase not be included in a report for car expenses?


since a model car is a toy, i would just tag it "toy" ?

for me, this example is not an argument against tags. if you have categories and there is a category "car" and you put the model car into that category it will also show up in the car expense report ... both times it would be a user error.

_________________
cheers,
Holger (project coordinator)


Top
 Profile  
 
 Post subject:
PostPosted: Sun Nov 11, 2007 4:31 am 
Offline

Joined: Fri Nov 09, 2007 7:08 pm
Posts: 9
To only be able to use the tag 'toy' seems to restrictive. What if a user is really into toys or models in a big way. They would then want to distinguish between toy car and toy tank. The problem with using the tags 'toy car' or 'toy tank' is that we could then not create a report on just transaction with the tag 'toy' unless we also included the tag 'toy' with the tag 'toy car' or 'toy tank'. If we use the tags 'model' or 'toy', and 'car' to tag the model car transaction we still have the problem of this transaction showing up in our real car expense report.

_________________
kiss my tulips, not my cheeks


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 16 posts ]  Go to page 1, 2  Next

All times are UTC + 1 hour [ DST ]


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron




Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Style supported by CodeMiles Team.