Are Tables Required Or Not?

[CodeTRUCKER]

After reading SuperBoyAC's excellent treatise on "information collectors" I thought I would examine if I was using the most efficient tool for my purposes (nothing special).  In my examination of one of the products I found a complete lack of support of tables unless I copy/pasted.  Given the developer is a most gracious person and quite competent in coding, I decided to remove myself from the exalted throne and ask myself *if* my long-held persuasion that tables were/are indispensable for collecting/organizing/presenting/storing data.

My question is... if tables are not used how does one handle the data normally contained in tables?  


FWIW - The software I am considering has everything else I need except tables.  This is the only caveat I have to overcome.

[edit]
My primary purpose for using tables is to arrange data in numerous grids of related and structured information in order to evaluate different related entities.  I do this so various items can be compared as to determine the "best" choice.  Once I have made a decision the table serves as a referential repository.  It is not uncommon for me to edit the tables numerous times a month.  You might call my grids, "Living Tables."  I hardly ever store data in any other form.  As an example, I use a table to create characters for my fiction.  Each row is a character with the columns being criteria of the character's person (eye color, hair color, build, temperament, etc).  This allows for great checking and cross-referencing of the necessary conflicting attitudes and temperaments which allows those wonderful dramatic tensions.
[/edit]

[peter.s]

"After reading superboyac's excellent treatise on "information collectors""

Could you share the link please?

"how does one handle the data normally contained in tables"

Well, that would depend both on the origin of the data you normally would have put into the table, and on the USE you ideally would have made of that data (if it were stored in a table) - from that point on valid advice would be possible, not without that knowledge.

I'll give two examples:

- some IMS come with "columns"; unfortunately, it's a trap to put data into those "columns" = item attributes, in most cases, bec such data will not be exportable ever after, or with difficulty

- if you don't need "live", frequent writing access to your data, why not link an item containing a .jpg of the table, to the original table? (of course, broken links probs could then occur, without proper planning: If you don't have hundreds of such external tables, putting them all together in just one directory would be preferable to splicing them up into numerous folders-by-context (= you would organize context within your IMS, not try to double it within the file system, for these)) (also, for memory/fast display reasons, is Excel mandatory, in such a coupling, e.g. for need of elaborate data processing, or is it simply a set of un-touched values, where tiny MS Works or other simple spreadsheets could be linked instead? There might be free offerings for very simple tables) (Also, a short macro could automatically load the respective original file, whenever you then display such a "special" item, even for frequent writing access, if needed; in such cases, even the copying of the "pic" of the table into the item would be counterproductive, since most of the time, the pic would be out of sync (or synching would be too much fuss) - here, just the item's title, in the tree, could contain the link, which would omit the intermediate step of first going to the content field of the item, then to trigger the link only)

As said, it all depends on the origin (and extent) of the data, and your typical access to it; just for reading of seldomly changed data, a pic of the original file, plus the link to it, would be best.

[CodeTRUCKER]

...

Could you share the link please?

"how does one handle the data normally contained in tables"
...

Sorry for being vague.  I edited the OP accordingly.

The "treatise" was the review Aram put together on note taking software, "Notetaking Software Roundup #1."  You'll understand why I chose the words, "information collectors" should you make it through the review. 

[TaoPhoenix]

(Raw Post)

It looks like about 2014 we're all starting to look at these "Information Programs". When you get a personal winner program, it's the only one you recommend. So I keep testing my pick, aka "MyInfo" against new uses.

This time for tables, it might work.

Let's try this screenshot.

[attachimg=#]

So that is a "table" pasted from Open Office, lines 1-2. Then in MyInfo, I "corrected" a line already there, and added new data.

So ignoring the Version Control issues, is that close to what you need?

[dr_andus]

My question is... if tables are not used how does one handle the data normally contained in tables?

The alternative would be some kind of a hierarchical list (i.e. outline), whereby each piece of the column data is represented as a child of the row item (parent). It's a less efficient way of presenting information, as the list gets longer than the table would have been (you have to scroll down etc.), so it's just a workaround in situations when tables are not available or are a pain to construct (such as with wiki syntax).

[TaoPhoenix]

My question is... if tables are not used how does one handle the data normally contained in tables?

The alternative would be some kind of a hierarchical list (i.e. outline), whereby each piece of the column data is represented as a child of the row item (parent). It's a less efficient way of presenting information, as the list gets longer than the table would have been (you have to scroll down etc.), ...

Just reminding people that MyInfo lets you expand and contract parts of the list so you do not in fact have to waste time scrolling! So let's say you work on a big section for a while. Then it just becomes a reference source. So you compact it to the header and then it just sits there.

[dr_andus]

MyInfo lets you expand and contract parts of the list so you do not in fact have to waste time scrolling!

I was making a different point. In a table you see the child info horizontally in the same row (i.e. it's in the line of sight), while to view the same info as an outline you may need to scroll down, especially with more complex tables. Of course you can collapse outlines, but then you won't see the data in the collapsed bits, so it would be more difficult to review that information as in a table.

Actually, an option that's closer to a table-like organisation is a mind map (such as Freeplane). Then the info is still more horizontally presented than a traditional vertical outline.

[TaoPhoenix]

MyInfo lets you expand and contract parts of the list so you do not in fact have to waste time scrolling!

I was making a different point. In a table you see the child info horizontally in the same row (i.e. it's in the line of sight), while to view the same info as an outline you may need to scroll down, especially with more complex tables. Of course you can collapse outlines, but then you won't see the data in the collapsed bits, so it would be more difficult to review that information as in a table.

Actually, an option that's closer to a table-like organisation is a mind map (such as Freeplane). Then the info is still more horizontally presented than a traditional vertical outline.

Ah, got it. And that's quite true. So it def depends on the type of info being worked with.

[Vurbal]

MyInfo lets you expand and contract parts of the list so you do not in fact have to waste time scrolling!

I was making a different point. In a table you see the child info horizontally in the same row (i.e. it's in the line of sight), while to view the same info as an outline you may need to scroll down, especially with more complex tables. Of course you can collapse outlines, but then you won't see the data in the collapsed bits, so it would be more difficult to review that information as in a table.

Actually, an option that's closer to a table-like organisation is a mind map (such as Freeplane). Then the info is still more horizontally presented than a traditional vertical outline.

One of the nice things about Freeplane or Freemind (also XMind and probably other mind mappers) is the many ways you can transform either the visual map or the underlying data for use with other software. You can export a map to a simple image, transform the underlying data to all kinds of different formats, or even read the XML directly with another program.

For example let's say you wanted to integrate a mind map with Evernote since it's the only program on the list I have even passing familiarity with. I believe you could just export to HTML and then import that directly into Evernote. If you update the map you simply export it again and Evernote should be able to stay updated automatically.

During the brief period I worked with Evernote I didn't experiment with local resources so it may not be quite that simple. And obviously the complexity would depend on your particular choice anyway.

Of course the downside of this approach is having to do all the editing outside your information managers. Since Freeplane is Java based and the maps themselves are just XML, or whatever format you export to, it's certainly possible to get around that with the right IM. However it would likely require some significant time and effort to make it work.

[CodeTRUCKER]

I appreciate the replies, but it appears (at least for my needs) tables are required and any software which does not allow some form of basic (and searchable) table structures just simply won't cut it.  This eliminates Surfulater and MyBase (MyBase does provide RTF tables, but any data in a table is not searchable AFAICT).  The idea of using mind maps may have some potential as quasi-tables as long as one doesn't lose other necessary functions, but I digress...  The topic here is are tables essential?

[off topic]
@TaoPhoenix - Kudos!  I have given MyInfo a good once-over and it has the best table features (sans a "live" column and row sizing like in Evernote) I have found so far, but there are additional functions I need to test.  MyInfo has a nice, easy feel to it which I like.  MyInfo is off to a good start in my !
Time will tell.
[/off topic]

[dr_andus]

The topic here is are tables essential?

Well, I'm not sure what you're getting at then. It seems like you have already decided that tables are essential for you. So what are you asking? Are you looking for software that have good support for tables OR are you looking for arguments to convince you that tables are not essential?

[CodeTRUCKER]

The topic here is are tables essential?

Well, I'm not sure what you're getting at then. It seems like you have already decided that tables are essential for you. So what are you asking? Are you looking for software that have good support for tables OR are you looking for arguments to convince you that tables are not essential?

Yes, tables "are" essential for me, but as stated in the OP, I am willing to concede what I have come to accept as "best for me" may be too narrow a scope.  As a result, I am attempting to open up my perspective to allow other ideas.  So, the answer to both your questions is, "Sort of, Yes."  Again my real question is if tables can be eliminated as a tool in data storage/presentation?  My present myopia says, "No."  So, until an argument can be made for not using tables, I'm stuck with my present understanding.  Although finding the "right" software will be beneficial, my purpose in this thread has migrated to the larger question concerning the necessity of tables.  I am finding the question provocative and fertile ground for discussion.  Maybe I'll learn something.  

Consider Surfulater.  A powerhouse piece of software in almost every other respect, but there is no native provision for tables.  This blows my mind!  Neville is obviously a very intelligent person, but he did not include tables as a feature!??  This leaves me asking "why?" which provokes me to re-examine my understanding.  I find myself asking, "What does Neville know that I don't?" (yes, I have asked, but we are only in the middle of that conversation).  The bottom line is... if Surfulater and a good number of other "information collectors" do not have native table features, what paradigm of form and function is being used?  Hence, this thread.  I hope this makes sense?

[tomos]

[edit]
My primary purpose for using tables is to arrange data in numerous grids of related and structured information in order to evaluate different related entities.  I do this so various items can be compared as to determine the "best" choice.  Once I have made a decision the table serves as a referential repository.  It is not uncommon for me to edit the tables numerous times a month.  You might call my grids, "Living Tables."  I hardly ever store data in any other form.  As an example, I use a table to create characters for my fiction.  Each row is a character with the columns being criteria of the character's person (eye color, hair color, build, temperament, etc).  This allows for great checking and cross-referencing of the necessary conflicting attitudes and temperaments which allows those wonderful dramatic tensions.
[/edit]

I think a database type IM might be what you need here. You can create fields/columns for the different attributes. But you would have many advantages over simple tables:
you could e.g. have sub-items/hierarchy under each character with related ideas
you can give items multiple parents i.e. show in multiple locations
sorting can be a lot easier than with tables, although this might not be an advantage if writing within the "table"

Worth checking out this thread too: For Serious Research: Cadillac of "ClipBoard Managers" vs. "Info/Data Manager". There are other ideas there that may well suit better.

[dr_andus]

Again my real question is if tables can be eliminated as a tool in data storage/presentation?

OK, thanks for clarifying. I'd break down your question a bit further. There are two underlying assumptions there: 1) that there is (or should be) just one general way of working with data for everyone (with or without tables), and 2) that it is necessary or desirable to have all the solutions present in one single software.

Concerning 1), I'd say that people's information-related tasks vary so much that one workflow (working with or without tables) will never cover everyone's needs. Concerning 2), there may be benefits for using two or more different systems together to cover a workflow.

So it should be possible to use an information management (IM) software that does not have good support for tables most of the time, and occasionally resort to software that specialises in tables for the odd table-related tasks. A decent IM software should allow you to import the table somehow (as text or as image) or at least link to the file with the table, so it can be launched from within the IM, which can serve as a project hub (dashboard) for the given task group.

In fact this is exactly my situation. I use ConnectedText (a personal wiki) for my database and information analysis. But creating tables is a pain in CT (at least for me), so if I need to work out a problem using tables then I use Treesheets or an Excel sheet, and then I link to those files from CT or take a screenshot and insert the image into the CT document.

Similarly, since CT is mostly a text-based system, I prefer to use Surfulater for capturing and storing webpages, but if it's an important page for a particular CT document, I can link to the captured webpage in Surfulater from CT directly. So you can have your cake and eat it. 

But if tables are crucial for you, why not make a software that is strong with tables the centre of your system, and use other 'satellite' software to complement the tasks that it might not cover? In fact wouldn't InfoQube fit the bill?

[CodeTRUCKER]

[edit]
My primary purpose for using tables is to arrange data in numerous grids of related and structured information in order to evaluate different related entities.  I do this so various items can be compared as to determine the "best" choice.  Once I have made a decision the table serves as a referential repository.  It is not uncommon for me to edit the tables numerous times a month.  You might call my grids, "Living Tables."  I hardly ever store data in any other form.  As an example, I use a table to create characters for my fiction.  Each row is a character with the columns being criteria of the character's person (eye color, hair color, build, temperament, etc).  This allows for great checking and cross-referencing of the necessary conflicting attitudes and temperaments which allows those wonderful dramatic tensions.
[/edit]

I think a database type IM might be what you need here. You can create fields/columns for the different attributes. But you would have many advantages over simple tables:
you could e.g. have sub-items/hierarchy under each character with related ideas
you can give items multiple parents i.e. show in multiple locations
sorting can be a lot easier than with tables, although this might not be an advantage if writing within the "table"

Worth checking out this thread too: For Serious Research: Cadillac of "ClipBoard Managers" vs. "Info/Data Manager". There are other ideas there that may well suit better.

Tomos,

Thanks for the suggestion, but unfortunately, I don't really understand what you are getting at with "database IM?"  Perhaps after I digest the link you provided I will have a better grasp.  I know I am missing something here, but I don't know what. 

[CodeTRUCKER]

Again my real question is if tables can be eliminated as a tool in data storage/presentation?

OK, thanks for clarifying. I'd break down your question a bit further. There are two underlying assumptions there: 1) that there is (or should be) just one general way of working with data for everyone (with or without tables), and 2) that it is necessary or desirable to have all the solutions present in one single software.

Well, given I need to do global searches often, splitting up my data collection is not really tenable, so yes, I do need to have all my data in a single repository.

Concerning 1), I'd say that people's information-related tasks vary so much that one workflow (working with or without tables) will never cover everyone's needs. Concerning 2), there may be benefits for using two or more different systems together to cover a workflow.

So it should be possible to use an information management (IM) software that does not have good support for tables most of the time, and occasionally resort to software that specialises in tables for the odd table-related tasks. A decent IM software should allow you to import the table somehow (as text or as image) or at least link to the file with the table, so it can be launched from within the IM, which can serve as a project hub (dashboard) for the given task group.

A valid observation, but again my need for global recall precludes multi-program schemes.

In fact this is exactly my situation. I use ConnectedText (a personal wiki) for my database and information analysis. But creating tables is a pain in CT (at least for me), so if I need to work out a problem using tables then I use Treesheets or an Excel sheet, and then I link to those files from CT or take a screenshot and insert the image into the CT document.

Similarly, since CT is mostly a text-based system, I prefer to use Surfulater for capturing and storing webpages, but if it's an important page for a particular CT document, I can link to the captured webpage in Surfulater from CT directly. So you can have your cake and eat it. 

I have used CT in the past (I may still have a license), but I stopped using it due to some anemia (I can't recall what?).  Surfulater is a bonnie piece of kit, to be sure.  If it had native table features we would probably not be having this conversation.   One of my favorite features is the intelligent way it handles grabbing and formatting web sites.  Out of the box, I clipped a forum thread on turbine engine performance and settings for a DeHavilland Twin Otter.  Surfulater somehow intelligently excluded the superfluous junk and present the thread in a concise format that was far more enjoyable to read.

But if tables are crucial for you, why not make a software that is strong with tables the centre of your system, and use other 'satellite' software to complement the tasks that it might not cover? In fact wouldn't InfoQube fit the bill?

InfoQube, eh?  It has been a long time since I have read that name.  Unfortunately, my gimpy memory will not release the details of my involvement at present.  I will have to return to the scene of the crime to re-familiarize myself.

[CodeTRUCKER]

Meanwhile, back at the ranch...

I have been thinking about the larger question of this thread.  I have been thinking of (1) what a table really is and why it was, is used?  I have also been questioning (2) what is really happening with tabulated data?  Now, I'm no great thinker, but (at least for me) this exercise has helped me to reduce the subject to a finer granularity and has allowed me a more objective consideration.  Read on.

(1)  The first thought I had was a table is convenient.  It stores/presents related data in a matrix that is both familiar and efficient.  I think this is because its function is reinforced by its form.  Even the visual framework allows us to quickly navigate the data in a well-seasoned procedure.  Our eyes lead our minds around the grid for whatever purpose.  Tables are as comfy as our favorite chair, but mainly for graphically-oriented people which appears to be the vast majority of humankind.  On the other hand, the familiar arrangement of tables may turn out to be a prison for textually-oriented folk.  They are locked behind the bars of the grid lines without freedom of their minds to work in their behalf.  The table, like a movie inexorably leads us wherever the film maker wants us to go.  Perhaps tables imprisons all of us?  This leads me to the next bullet.

(2) In consideration of the dynamics of tables and the interactions of the user, the table is a collection of relationships.  But, it does not necessarily follow that all those relationships *must* be kept in proximity.
[Note: to the Reader:  I must admit that at this point I get kind of fuzzy trying quantify these dynamics, but I will a least try to communicate my thoughts.  Please don't ridicule me if I can't make things coherent.  At this juncture I am only working through the theory of my cogitations.]
As I looked at a table I saw separate entities within the matrix (no pun intended).  Associations specific to various entities tried to emerge, but was never really able to overcome the gravitational forces of the table.  However, this does not mean those associations could not live outside the table, but this did provoke a question of whether the different associations "needed" each other to remain coherent?  Is it possible the groups of associations did not necessarily require the table, but only needed a different proximal relationship to maintain their vitality?

Well, that's as far as I got this go-around.  Keep in mind, I am trying to communicate a "picture" which briefly surfaced and returned to the depths without revealing its true and comprehensive form.  I can kind of "see" what I am trying to say, but I can't put into words or concrete application just yet.  I hope you all do not think me mad?  

[tomos]

Tables are, as you say, limited. They're very limited in fact.
An outline within a table offers more possibilities.

Following up on what dr_andus described as an IM "that is strong with tables".

Think outline, tables, the possibility to show items in multiple locations, filtering, etc. etc.
Think of a family shown in an outline, children will be shown under each parent and parents will be shown under grandparents.

[attachthumb=#]

or,
every person can be shown at the top level, with children as, eh, child items, which means many people are shown multiple times.

[attachthumb=#]

This is using InfoQube. It is very powerful - I'm only a basic user myself, I struggle myself sometimes with e.g. the hierarchy/display options. What I'm trying to say is: that strength comes with a highish-learning-curve price.) Basic filtering is easy, very complex filtering is possible but not (yet) easy.

I linked spouses to each other. You could also create other subitems, related to each character and choose to show these or not. There is also a HTML pane where you can add further text (tables even!), etc, etc.

[TaoPhoenix]

...
A valid observation, but again my need for global recall precludes multi-program schemes.
...
Well, given I need to do global searches often, splitting up my data collection is not really tenable, so yes, I do need to have all my data in a single repository.

I just try to live with an uneasy merging of info. What Excel/clones do really well is that sometimes data arrives requiring dynamic math abilities and linked pages. For me that's really hard to take out of the spreadsheet programs.

Other hobby data just lives in windows folders as various files that are hard to reconvert and merge anywhere else. I will make a small joke that I visit the same 120 hobby topics ten times a year. So I just collect misc notes, try to put really good file names on them, and run my "Drive Reader" about four times a year. Then I can just search the text file for that thing I looked at five months ago.

[TaoPhoenix]

Meanwhile, back at the ranch...

I have been thinking about the larger question of this thread.  I have been thinking of (1) what a table really is and why it was, is used?  I have also been questioning (2) what is really happening with tabulated data?  Now, I'm no great thinker, but (at least for me) this exercise has helped me to reduce the subject to a finer granularity and has allowed me a more objective consideration.  Read on.

(1)  The first thought I had was a table is convenient.  It stores/presents related data in a matrix that is both familiar and efficient.  I think this is because its function is reinforced by its form.  Even the visual framework allows us to quickly navigate the data in a well-seasoned procedure.  Our eyes lead our minds around the grid for whatever purpose.  Tables are as comfy as our favorite chair, but mainly for graphically-oriented people which appears to be the vast majority of humankind.  On the other hand, the familiar arrangement of tables may turn out to be a prison for textually-oriented folk.  They are locked behind the bars of the grid lines without freedom of their minds to work in their behalf.  The table, like a movie inexorably leads us wherever the film maker wants us to go.  Perhaps tables imprisons all of us?  This leads me to the next bullet.

(2) In consideration of the dynamics of tables and the interactions of the user, the table is a collection of relationships.  But, it does not necessarily follow that all those relationships *must* be kept in proximity.
[Note: to the Reader:  I must admit that at this point I get kind of fuzzy trying quantify these dynamics, but I will a least try to communicate my thoughts.  Please don't ridicule me if I can't make things coherent.  At this juncture I am only working through the theory of my cogitations.]
As I looked at a table I saw separate entities within the matrix (no pun intended).  Associations specific to various entities tried to emerge, but was never really able to overcome the gravitational forces of the table.  However, this does not mean those associations could not live outside the table, but this did provoke a question of whether the different associations "needed" each other to remain coherent?  Is it possible the groups of associations did not necessarily require the table, but only needed a different proximal relationship to maintain their vitality?

Well, that's as far as I got this go-around.  Keep in mind, I am trying to communicate a "picture" which briefly surfaced and returned to the depths without revealing its true and comprehensive form.  I can kind of "see" what I am trying to say, but I can't put into words or concrete application just yet.  I hope you all do not think me mad?  

Great higher level comment! My eleven cents:
1. "What a table really is and why it was, is used?" - To me, a table is "very flat and wide data that desperately needs a 2x2 correlation to everything all the time".

So supposing for example in my tax prep job, I'd want a table of:

Last name, First Name, Last 4 of the social security number, full social security number, and client phone number ...

and then IRS acceptance status plus refund-check status.

That kind of data is a chart against which at any time a client calls in and "wants to know the last two items as fast as possible". Client calls, they give you any amount of the first five items, and you feed back the last two.

That's what a chart does. 2x2, very tall and very wide, but with a little care, *very flat*.

2. Trees
However, a whole lot of my mindset runs to very *deeply nested* data that emphasizes structure of the data.

Recreation
  DonationCoder
      CodeTrucker
          MyInfo Investigation
              Necessary Features
                 1 (Feature1)
                    Progress1
                        Progress 1a
                        Progress 1b
                    Solution1
                 2 (Feature2)
                     Progress2
                        Progress 2a
                        Progress 2b
                    Solution2
   Slashdot
   Aphelion
   Chessbase
      Article1
         Notes1
         Notes2
      Article2
         Notes1
         Notes2

--------------------------------------------
And so on.

So in that broad case a table is useless because the structure rules it all, and then the rest starts to get freeform.