Blog: Posts from September, 2015

We were surprised to learn that Iron Speed, Inc. has decided to discontinue operations. The primary reasons were cited by the company CEO as “expense of litigation with patent troll” and “product sales have been severely impacted”.

Iron Speed has always been a product that generates a large number of data input forms from database tables. These data input forms were based on aging Web Forms technology virtually abandoned by Microsoft. The fact that “product sales have been severely impacted” indicates the possibility of IronSpeed going out of business even in the absence of litigation.

Code On Time has been focused on generating custom premium database applications with a solid extensible architecture. Our own Data Aquarium Framework and a concept of a data controller make it possible. We are inviting all Iron Speed customers to attend a live WebEx presentation of Code On Time. We will show you amazing Touch and Desktop UI in action, perform live project modifications, and answer any questions you may have. Open a support ticket to request a presentation.

Our Technology

A data controller defines an entity with a data model expressed as a collection of fields. Individual views describe presentation of data, while actions and business rules define the built-in and custom application behaviors.

Code On Time application generator is a single executable program for Microsoft Windows that allows creating custom software projects. The intended operator of the application generator is a software developer, who has designed a database and wishes to create a custom application source code for it. Several project types are supported and differ by deployment model of the source code “written” by application generator.

Premium database applications created with Code On Time may include content pages and data-aware pages.

A typical use case of the application generator would be the following: a software developer starts the application generator, selects a database for the project, and chooses to create the project source code without data controllers or to have data controllers configured from the database.

• A project without data controllers must be populated with pages and controllers manually. A data controller can be configured to consume data from external web services or file system. The developer may also create a custom SQL statement to configure a controller.
  
  Use this option if you are developing an application on top of stored procedures or web services.
   
• A project may have data controllers configured from the database tables. Application generator will de-normalize existing table relationships and define a singular entity that presents a user-friendly logical view of data. De-normalization of relationships is mandatory for a premium application.

For example, a database may define three separate tables to persist products, categories, and suppliers. The table of products would reference categories and suppliers via a numeric values instead of including the name of category or supplier information. Application generator will configure a data controller for products by “borrowing” fields from categories and suppliers.

The application generator has completed its work after the source code of the project has been generated.

The application developer needs to publish and deploy the source code to a web server to see the generated application in action. Microsoft IIS or IIS Express web server is required for an application to come alive.

End user must operate a web browser to access an application deployed to a Microsoft web server. All major web browsers are supported.

Non-human agents can also interact with the application data controllers via REST API if the software developer configures this type of interaction.

If the database has changed, then the application developer will have to update data controllers and produce a new source code for the application. The old application will have to be physically removed from the web server and replaced with the new published application.

Applications created with Code On Time are not able to detect changes in the database schema. Changes in the database schema will either render application inoperable or remain invisible, depending on the nature of database modifications.

An application created for one database is unique and will not work with a database that has a different schema.

Database metadata with information about tables, columns, and relationships is not included with the published application. Metadata about the database is not used by the application when serving requests from web browsers or external non-human agents.

Fundamentally our application generator is an automation tool for software developers that provides a service of writing the source code of custom line-of-business applications.

Microsoft Visual Studio can be used to customize generated source code.

Introducing Universal Database Browser

The claim of patent infringement against IronSpeed, Inc. mentioned above is based on the patent with the following abstract:

Computer software for, computer apparatus for, and a method of automatically generating a user interface for a relational database comprising extracting schema information from the relational database and automatically generating corresponding schema and user interface metadata, storing the metadata in a repository, and automatically developing from the metadata a user interface appropriate to the relational database.

The first reading of the abstract will certainly cause anyone familiar with software development to scratch their head. There are virtually no applications that do not rely on a database in some way. Databases can be found in computer gaming, accounting, word processing, anti-virus protection, health care, package delivery - you name it. There is virtually no application code that does not rely on user interface metadata generated by computer software in some shape or form. How could this generic idea be awarded a US patent?

The second reading of the abstract will show that the word “code” is not mentioned at all. You will not find the word “code” in the claims section of the patent either. So if it is not about code generation then what does “automatically developing from the metadata a user interface appropriate to the relational database” mean?

A thorough reading of the entire patent and review of 87 illustrations will reveal that it does introduce a rather neat invention in the form of a Universal Database Browser.

1. The invention includes a utility that we shall call Metadata Extractor. The purpose of this utility is to convert information about tables, columns, and relationships between tables into user interface metadata.
    
2. The main component of the invention is the utility that we shall call Universal Database Browser. This browser interprets user interface metadata and displays data input forms at runtime.  
    
3. The invention also makes provisions for the possibility of enhancing user interface metadata with custom scripts containing business rules and triggers.

Database administrator will utilize Metadata Extractor to produce and refresh user interface metadata after each round of database schema changes. User interface metadata about the database is stored in a central location.

An instance of Universal Database Browser is deployed to a computer of each end user. Browsers are configured to access the central location of user interface metadata files.

End user starts her Universal Database Browser and chooses metadata retrieved from the central location by database name. The browser will display a menu of available entities. A list of data rows is displayed after entity selection has been made.

End user can activate a data entry form for any row. She we also see a collection of directly linked child records. For example, if an order is selected then a data input form is displayed for that row along with linked data tables.

Any child record or entity can be promoted to become a focus of Universal Database Browser. The browser is the sort of a looking glass that is being moved by end user from a data row to the row’s linked entities in various directions.

Universal Database Browser also supports an interesting concept of “search path”, whereby search operations are traveling connected data entities to help locating data.

Note that Universal Database Browser is a smart software capable of interpreting user interface metadata to provide all of these capabilities to the end user. Not a single line of code has to be written. The browser is the embodiment of the central idea expressed in the summary of invention:

“It is the primary object of the present invention to provide a method and system by which data entry forms for relational databases may be generated dynamically at run-time without the necessity of writing computer code to accomplish this task.”

The invention is certainly worthy of finding a venture capitalist willing to fund it or maybe having a “Kickstarter” project started.

We believe that it is not possible to provide a truly premium database application experience with such a literal interpretation of database information. End users do not see their data in 1st, 2nd, 3rd, and 4th normal forms. The real-world data is inherently de-normalized and shall be presented as such.

The invention will find traction among database administrators and software developers who need a “native” look at data in its fully normalized glory.

Code On Time vs. Universal Database Browser

Please note that the terms Metadata Extractor and Universal Database Browser are used in an attempt to simplify references to the ideas expressed in the patent.

It is our opinion that Code On Time code generator and Universal Database Browser are two different animals. Let’s compare the two.

Does Code On Time perform substantially the same function as the invention?

Code On Time is designed to assist developers in writing source code for their line-of-business application. The invention is intended to eliminate any need to write source code. The answer is a resounding “no”! Our very name, “Code On Time”, seeks to imply that code is in our DNA.

Does Code On Time function in substantially the same way?

Our code generation product does not serve the same function. Code On Time produces source code, while the invention eliminates source code. The answer is “no”.

Does Code On Time yield substantially the same result?

Code On Time produces source code for an application developer. This developer will compile and publish this code to a Microsoft web server. Any web browser or non-human agent can make requests to interact with the application. The invention produces user interface metadata, and interprets this metadata as data input forms to the user. Again, the answer is “no”.

Applications created with Code On Time use a well defined entity model that prescribes presentation of data as grid and form views and determines transition of views via actions. Data may come from any source. For example, a developer can defined an SQL query or stored procedure to read data from the database. An entity can also be programmed to read/write data from a web service, file system, or any other source. Application framework interprets the entity and displays data in various view styles. For example, a typical grid view can be rendered as responsive grid, list, collection of data cards, map, and charts. Request an interactive Webex presentation to learn more.

“Calendar” is a brand new view style that will become available with update 8.5.5.0 on September 2, 2015 . A presence of a “date” field will tell application framework that there is possibility of rendering data as a calendar. New view style offers Day, Week, Month, Year, and Agenda modes. Any field in the view can serve as a “color” field. The framework will assign a color to each data value.  End users can drag and drop events to change values of date fields. Standard form view of an entity is display when an event is selected enabling seamless editing of data.

“Day” view in the screen shot shows 4 data records rendered as events.

Mini calendar on the side bar uses bold font to indicate dates of the month with events. Mini calendar alternates presentation of data between day and week mode when a particular date is clicked. Color legend shows associated data values, which represents the name of the employee assigned to the “order” event. An “event” is a record from Orders table of the Northwind sample.

“Week” view offers seven days of events. Future updates are expected to support 3 and 4 day weeks. Both “Day” and “Week” view are infinitely horizontally scrollable.

“Month” view offers infinitely scrollable events organized in months.

Click on any item in the color map on the sidebar and the application will “dim” events associated with other employees in “Day”, “Week”, “Month”, and “Agenda” views.

“Year” view offers analytical presentation of an entire year and also enables quick data-driven navigation to a month or a specific day.

“Agenda” view provides a convenient condensed summary list of events with a dynamic timeline.

All modes of the calendar view style are responsive. Smartphone users will see presentation scaled to fit the form factor of their device. For example, these two screen shots demonstrate “Day” and “Agenda” view on a typical smart phone.

These amazing capabilities require no programming or coding. Developers can opt to disable the calendar when not desired. Otherwise application will simply offer the end user yet another way to see their data.

Calendar view now joins a first class collection of presentations styles that were made available in the previous releases and greatly enhanced with this new iteration. View selector and sidebar provide access to every view style available for a particular dataset.

For example, charts view displays automatically constructed charts without developer writing any code.  Any number of custom charts can be defined when needed at design time.

“Cards” view presents data items as multi-line cards with the same size. Application framework breaks each three fields in paragraphs offering another way to see data. Cards presented in 3, 2, or 1 column based on the screen size. The screenshot shows two columns of automatically configured cards.

“List” view is the most universal presentation style that will work with fields of any length and any screen size. Field values float from left to right and continue on the next line.

“Grid” view style enhances responsive presentation by introducing automatic data balancing. The new release reduces the number of visible columns by applying 2, 5, 8, 10, and 12 column breakpoints based on screen size when data is rendered. This makes it possible to display a grid of rows with “important” fields without being forced to scroll horizontally. For example, this screenshot shows five columns of data rows in Orders table.

Developers can indicate the minimal screen size that a particular column must be displayed on. For example, tag “grid-tn” will force a column to show up even on “tiny” screen. Small screes with show every column marked as “grid-sm”. The release notes of the update will explain expected logical pixels of tiny, extra small, small, medium, large, and extra large screens.

Previous release required explicit tagging of each field. The new approach is to assume that all fields must be displayed if possible. The mere intent of a developer to place a field in a grid implies that it must visible. Developer-defined tags simply enforcing display of fields on particular screen sizes in responsive grid. The next screenshot shows 8 columns displayed when the sidebar is not visible. Automatic data balancing ensures that “shorter” fields reclaim more real estate from “longer” fields with enforced minimal width to ensure quality “balanced” presentation of data in columns with fixed width.

All view styles also support “long press” that allows displaying of context menu and selection of records on both desktop and touch-enabled devices. The screenshot above shows context-sensitive filtering and sorting options.

“Map” view style is one more method of presenting data that becomes available when latitude/longitude or Address/City fields are present in the gird view.

Context menus and data cards are now displayed at the bottom of the screen on devices with small form factor to enable easy touch operations. A couple of screenshots below show data card of “Map” view style and view selector on a small screen.

The standard collection of presentation styles will be enhanced with horizontally scrollable “Datasheet” view and “Hierarchy” view styles. The implementation of remaining view style is well under way and is based on horizontal scrolling mechanism that was developed and perfected with “Calendar” view.