From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Scott Jaderholm" Subject: Re: Duration Tally Date: Fri, 22 Jun 2007 13:06:01 -0600 Message-ID: References: <20070613134706.GA10452@odin.demosthenes.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1I1oSL-0007zd-DZ for emacs-orgmode@gnu.org; Fri, 22 Jun 2007 15:06:05 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1I1oSJ-0007xc-Mk for emacs-orgmode@gnu.org; Fri, 22 Jun 2007 15:06:04 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1I1oSJ-0007xR-F4 for emacs-orgmode@gnu.org; Fri, 22 Jun 2007 15:06:03 -0400 Received: from nz-out-0506.google.com ([64.233.162.233]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1I1oSJ-0001uj-0j for emacs-orgmode@gnu.org; Fri, 22 Jun 2007 15:06:03 -0400 Received: by nz-out-0506.google.com with SMTP id q3so880135nzb for ; Fri, 22 Jun 2007 12:06:02 -0700 (PDT) In-Reply-To: Content-Disposition: inline List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Carsten Dominik Cc: emacs-orgmode@gnu.org On 6/22/07, Carsten Dominik wrote: > What I find a bit strange though is that it is using a hierarchy, > and every level of the hierarchy has the same columns. Columns > seem to make more sense for items with equal level, at least to me. I think it's harder to design an interface where different levels have different columns. Sometimes the columns will make sense on different levels so they opt to leave them there. Also, as we see in the screenshot, they can be used for summaries of almost anything that can be summed. A simple example where columns apply to different levels, other than summaries, is this: * Saturday Projects (In charge) ** TODO Clean yard Bobby *** TODO Rake Sue *** TODO Mow lawn John One thing I forgot to mention that I like about organizing information in trees with columns instead of tables is the flexibility in storing notes. * People (Phone Number) ** Family *** Ben 123-123-1234 :soccer: I can have information about Ben down here under his name that isn't necessarily organized in a structured manner. This could be notes or brainstorming or other things. - I can paste content from elsewhere here and mostly retain formatting - it can have newlines - it won't be visible in a summary - I can use bulleted lists - I don't have to type Family every time I add an entry - I can cycle visibility ** Friends *** John 123-123-1235 ** Work (Employee #) *** Steve 1 An equivalent table would look like: | Category | Name | Phone | Employee # | Notes | |----------+-------+--------------+------------+-----------------------------------------------------------------------------------| | Family | Ben | 123-123-1234 | | I have to create a separate column here for notes, and it won't let me have new lines | | Friends | John | 123-123-1235 | | | | Work | Steve | | 4321 | | If org ever gets columns, I would hope that they could be defined on a level smaller than for the entire file. I guess I've shown that it is possible to do basic columns right now, it just involves a lot of M-i and isn't very pretty. I can only imagine how much work a real columns implementation would take. Cheers, Scott