Building a Sparse Grid Through Attention Management

I have seen grids in UIs that have dozens of columns, and the user has to scroll right a page or two to see all of the items.

We can build UI grids that show only the columns a user wants or needs to see. Columns could be added and removed in the grid as desired by the user. We could build an attention management endeme or two to indicate which columns to show. Each column would have an endeme and a user would have an endeme to identify which columns they want to see. Using endeme matching the desired columns would be shown. The organization could also have an endeme identifying which columns are important in the business situation for each grid. In addition, columns with data changes, unusual values or critical values could be moved into those columns shown. Users could add and remove columns, changing their attention management endeme if they so desire when they do this.

The advantage of this is increased productivity by the user because their attention is managed toward what they need to see, i.e. cost savings. Another advantage of this is that many more columns could be included as possibilities in a grid. Instead of having a few dozen, the grid could handle a few hundred columns. More data when managed thorugh attention management endemes means a user that is smarter in their decisions resulting from seeing the data, i.e. cost savings and added business opportunity.

Advertisements

Design Endeme Sets to Model Information

How to Design Endeme Sets

Designed to Combine: Each characteristic in an endeme should be designed to combine with any of the others resulting in a large number of possible emergent properties as they combine.

I sometimes takes years: It sometimes takes years to develop a good endeme set. It has to be both compact in its length and perfect in its application and excellent in its ability to combine its elements. By perfect, I mean its combinations cover what it needs to cover and its combinations do not generate bunches of ‘invalid’ results.

You have to start abstracting: Once you have gone beyond 22 items.

To test an endeme set: you can test/develop an endeme set by thinking of something it should describe and seeing if the endeme set can produce an endeme covering it.

What about two endeme sets?: Sometimes you will need more than one endeme set to describe something, but at least one of them has to be really good and essentially capture the essence of the thing being described. Creating two at the same time to work together or to parcel out the domain space does not work well. Focus on one until you have it well done, then go and make another if there is more domain space to cover. For one thing, it’s hard to do functions for situations if you have multiple endeme sets completing a situation.

An Inner Platform is a Good Thing?

In figuring out how to work with information inside a computer program, I am working toward building an inner platform. The thing I have to watch out for is an anti-pattern called the “Inner Platform Effect”. The inner platform effect often starts out with a generic database that gets added to and enhanced until it becomes a replica (usually a poor and incomplete one) of one of the systems that it is built on top of. Most often the kinds of inner platforms built are replications of relational databases and operating systems.

It is possible to build an inner platform that replicates the capabilities and organization of a relational database. It is possible to build an inner platform that replicates the capabilities and organization of an operating system. It is possible to build an inner platform that replicates the capabilities  and organization of an object oriented software development system.

In data oriented software development the inner platform effect is an anti-pattern. The Inner Platform Effect – “The Inner-Platform Effect is a result of designing a system to be so customizable that it ends becoming a poor replica of the platform it was designed with.” This “customization” of this dynamic inner-platform becomes so complicated that only a programmer (and not the end user) is able to modify it.

Three things tend to lead to the creation of an inner platform

  • Users want something that they can modify themselves without having to have a programmer involved.
  • Programmers want to build something very generic because they do not know what precise needs their user have.
  • Programmers may realize deep down that the way forward in software development is to build a level above the level they are currently working. This may be the real reason programmers keep building them and suffering the consequences. Without information structures and theory, you simply can not build an inner platform that has added more capability than a database or object oriented approach. Any or all of these may be in play.
  • Programmers look at repetitive field handling code and think to themselves that there must be a way of abstracting it. You see (to oversimplify the situation) each column in a table ends up being a member in a class. A whole bunch of members tend to look the same, get set, changed and erased and displayed the same way, and the thinking is that there really should be a generic abstracted way to handle them.

Avoid the Inner Platform Effect

When you are building an inner platform there are some things you can do to avoid the inner platform effect:

  1. Do something the underlying platform cannot do or can do very poorly. This is my goal – to build an inner platform that works with information as well as data.
    Working with information is something that a database or an object oriented programming can barely do if at all. Usually when someone attempts to use one of these technologies for information, they end up with a snarl of excessively complex, nearly unmaintainable code.
    Endemes provide work-with-able information about the items in the ‘inner platform’. Information about the items is what inner platforms are normally missing.
  2. For simple information: avoid objects and attributes in the endeme tables. have only endeme strings, labels and ids
    • have the endeme id’s in the tables (objects) directly
    • the endeme is the value
  3. for endemized attributes/data:
    avoid objects in the endeme tables, each endeme for the data is its attribute
    – the endeme is the attribute, the endeme’s value is the data, the label is the name of the attribute
  4. for endemeized objects: This would be a generic database and full inner platform.
    I don’t know how to avoid building an inner platform here. I need much more experience working with 1,2,ad 3. above before I can hope to work with endemized
    objects without suffering the inner platform effect. The trick is, that in order to get this experience, I need to build a bunch of inner platforms, have them die their expected gory death due to the inner platform effect, and eventually figure out how to build a true information programming platform that does not suffer this.
    need to use level 4, can not do this properly until level 3 is well understood
    this would build an actual inner platform.
    – endeme lists would avoid the problem of not using the database for some of its excellent features.
    this is because the database would need to support custom indexes, (since information has no order) and functions and triggers to power those indexes, (since the database does these very well)
  5. Level 4 programming will be based on an inner platform. We need to build an inner platform for level 4 information programming. This will allow us to use knowledge representation in programming. Note to self: look to see if there are any successful knowledge representation inner platforms out there. OWL comes to mind.
  6. AI programming will be based on the knowledge representation programming and is possible once an inner platform is built for level 4 programming. The inner model has a column for id, key/field, and value.

More thoughts on avoiding the inner platform effect

  • how do I avoid the inner platform effect?
    • keep the inner platform really sparse in features
    • do a hybrid system
    • have columns for id(must have), field(in only its information format), and value(must have)
      • access by information, not ‘table’ and ‘key’
      • but an endeme list has endemes with labels, access by information, the endeme makes it different
      • have no search attributes, put these in regular table columns
    • don’t let a user modify it, only for programmers
    • build a solid infrastructure to hide the implementation details
    • implement in really slow steps, taking years and learning how to do each step well before moving on to the next one
  • how do I use the RDB for what it’s good for?
  • the question is what can I do with information?

Building a Successful Inner Platform

The inner platform effect is an intuition by programmers that we need to build a level above the data levels. However without the information oriented programming theory to base it on, inner platforms just generally only implement things that already exist. Thus they usually fail to build a level above data levels.

I want to take the inner platform above both the database, the OS and the object oriented program level. The challenge is to have the inner platform reach out to the rel platform it replaces to use the performance facilities of the real platform below. The inability of an inner platform to do this is the most common downfall for the inner platform.

An inner platform for a database:

  • table
  • column
  • row
  • relation
  • pk
  • value

An inner platform for object orientation/xml/json:

  • class
  • member
  • object
  • type
  • collection

An inner platform for an operating system:

  • path
  • folder
  • filename
  • parent
  • child

Generic Data Models

– object     attribute     value

From C2: Definitely not an anti-pattern, and it can often greatly simplify table design for some corner scenarios. Apart from giving rapid prototyping benefits it also helps with handling ‘jagged’ data. Instead of introducing null columns using GenericDataModel enables us to save only relevant data thereby actually decreasing complexity. Reporting and manual labor against the table can be handled via views as mentioned above. not

Entity–attribute–value model

  •     The entity: the item being described.
  •     The attribute or parameter: typically implemented as a foreign key into a table of attribute definitions. The attribute definitions table might contain the following columns: an attribute ID, attribute name, description, data type, and columns assisting input validation, e.g., maximum string length and regular expression, set of permissible values, etc.
  •     The value of the attribute.

From Wikipedia: As noted above, EAV modeling makes sense for categories of data, such as
 – clinical findings, where attributes are numerous and sparse.
Where these conditions do not hold, standard relational modeling (i.e., one column per attribute) is preferable; using EAV does not mean abandoning common sense or principles of good relational design. In clinical record systems, the subschemas dealing with patient demographics and billing are typically modeled conventionally. (While most vendor database schemas are proprietary, VistA, the system used throughout the United States Department of Veterans Affairs (VA) medical system, known as the Veterans Health Administration (VHA),[1] is open-source and its schema is readily inspectable, though it uses a MUMPS database engine rather than a relational database.)

We Need an Inner Platform for Information

We need an inner platform because the db and the language do not provide what we need and we need a platform that will.
the problem is based on members

When to Avoid EAV Models

We should probably avoid the EAV model. The definition of an EAV model is having tables in a database that contain three columns: object, attribute, value.

  • Either do information full up in a database or don’t do it at all in a database. Databases are designed for data.
  • Of course you have to store your information somewhere.
  • So something like an inner platform is needed for that.
  • But you have to avoid the inner platform effect which is to create a platform which does pretty much the same thing as the platform used to build it, i.e. creating a database in code using a database to store it in for example.
  • To avoid this you need to provide significant additional value in your inner platform. Information orientation allows you to do this.

Information technology … is a misnomer

In responding to Rees Morrison’s blog post “Information technology … is a misnomer” or seriously under-inclusive. I see the following situation. He quotes Michael Schrage as saying “The biggest impact of technology is not on information management, it’s on people management, it’s on relationship management, it’s on process management, it’s on systems management”.

Programming has failed to construct adequate structures and techniques to work with information inside a computer program. IT techniques really just work with data, rather than working with information. This is the core of the problem. With adequate information oriented approaches programmers could write programs that would help manage relationships, flow information, and respond to process changes. Without information approaches, programmers can not address these issues well.

Handling information flow would be enhanced by having the program being able to understand the information that is flowing. Responding to process changes would be enhanced by having information about the processes inside the program. For example the importance, meaning, priority,  and context of the process are all forms of valuable information for responding the process changes. These could all be put into code if we had the proper information oriented techniques to do so. Relationships require not only knowledge representation of the relationships but a relevant computer understandable description of the people being related. Information inside a program would facilitate both of these.