Towards the databasespreadsheet in the sky: NAXL
Quote from dandl on August 11, 2019, 1:07 amThat's quite a shopping list. That's more like Access than Excel, and it brings in the idea of design and code, making apps for other people to use.
A friend of mine once said you can build the data entry/view/update part of just about any business application using just one layout: a master detail view: a form and a grid to rule them all. And every report is either a master detail page or a total/sub-total continuous. That was 30 years ago, and really hasn't changed. He didn't have anything to say about dashboards or charts, they weren't around then.
Just keep in mind who the customer is. If it were me, yes, I like the idea of popping out a row into a form layout for data entry, but designing forms is not something I would do for myself to use. I don't think I would use a graphical expression builder, but I definitely would use a zoomable model and a text editor. Dashboard and charts, maybe. Trees and code packages? Dunno.
There's a functionality gap between Excel and Access, and I want to fill it for my own purposes, to help me design apps for other people to use.
It's a lot of functionality, but a lot of it already exists: It's simply Rel, but with Java in place of Tutorial D.
Except for the report generator. I've taken several stabs in the past at integrating Rel and BIRT, none that I was happy with. I'm going to give that another go.
I might use something preexisting for code editing, too -- I might use Eclipse. Eclipse is designed to be a generic application framework into which you put plugins for custom functionality. I'm thinking of inverting that, so that Eclipse (configured with the usual Java authoring plugins) becomes a code management plugin for my Datasheet.
I may have misunderstood: when you say you are your own customer, did you mean the developer you, but still making app things for other people to use?
Where I see the gap is for a product similar to Excel, Word, PowerPoint, System R, AutoCad, MathCad, Mathematica, Blender and a myriad of others: tools for the professional user, not the professional developer. Tools to get stuff done, where the stuff is (relational) data, not code.
[As I wrote that I realised: what about all the non-relational data: key-value, graph, XML-ish? Later.]
Quote from dandl on August 12, 2019, 12:42 amI may have misunderstood: when you say you are your own customer, did you mean the developer you, but still making app things for other people to use?
Where I see the gap is for a product similar to Excel, Word, PowerPoint, System R, AutoCad, MathCad, Mathematica, Blender and a myriad of others: tools for the professional user, not the professional developer. Tools to get stuff done, where the stuff is (relational) data, not code.
[As I wrote that I realised: what about all the non-relational data: key-value, graph, XML-ish? Later.]
Per a post I made above, whilst there's a clear distinction in job titles between various forms of user and professional developer, I don't think there's necessarily a clear distinction between what power users and programmers do. In a typical organisation, it's common for some combination of users/programmers to create a spreadsheet to hold some data, make a form or small application to simplify data entry or provide some ancillary value, pass that wee application to someone to fill in more data, get it back and do some processing to get results, send it to someone else to amend data in a column based on the results, import data from a database/CSV/spreadsheet/etc. to join with the results, create another form to fill in more data, send it to someone to update that data, get it back and release it as an application because a business process is developing around it, implement three new forms to handle a new requirement, rinse and repeat, etc.
If you do this the way most organisations do it -- mainly with Excel -- you wind up with a tangled, unmaintainable, error-and-duplicate-laden shared-via-email-and-maybe-Sharepoint mess. If you do this purely with conventional application development tools (like C#, Java, VB and various Web frameworks, but I also include Access, Sharepoint, etc. in this set), you (or the developers in the IT department) spend a day or week or month on step 2 ("make a form or small application to simplify data entry") whilst some power user impatiently email-launches a series of badly-written spreadsheets to do the same thing and you're back to the Excel problem.
I'm making a better way to rapidly handle the ongoing amorphous intermingling of ad-hoc app dev / data crunching / day-to-day data management that tends to be characteristic of daily administrative work in every organisation. It will suit me on the (mainly) application development end (where I earn coin as an external consultant, soon[1] using my new "datasheet" tool to amplify data-oriented Java programming and data crunching), but it will also hopefully suit power users (who minimally have some coding ability, if only simple expressions) on the data crunching and day-to-day data management side.
--
[1] Given an as-yet undefined value of "soon".
Quote from Dave Voorhis on August 12, 2019, 10:01 amQuote from dandl on August 12, 2019, 12:42 amI may have misunderstood: when you say you are your own customer, did you mean the developer you, but still making app things for other people to use?
Where I see the gap is for a product similar to Excel, Word, PowerPoint, System R, AutoCad, MathCad, Mathematica, Blender and a myriad of others: tools for the professional user, not the professional developer. Tools to get stuff done, where the stuff is (relational) data, not code.
[As I wrote that I realised: what about all the non-relational data: key-value, graph, XML-ish? Later.]
Per a post I made above, whilst there's a clear distinction in job titles between various forms of user and professional developer, I don't think there's necessarily a clear distinction between what power users and programmers do. In a typical organisation, it's common for some combination of users/programmers to create a spreadsheet to hold some data, make a form or small application to simplify data entry or provide some ancillary value, pass that wee application to someone to fill in more data, get it back and do some processing to get results, send it to someone else to amend data in a column based on the results, import data from a database/CSV/spreadsheet/etc. to join with the results, create another form to fill in more data, send it to someone to update that data, get it back and release it as an application because a business process is developing around it, implement three new forms to handle a new requirement, rinse and repeat, etc.
I rather think you're missing my point. Yes, such things happen. Not any place where I work, but somewhere. Set them aside.
Have you never worked in a professional consulting environment where highly skilled people use a range of tools of their own choosing, and do none of the above? Where there is no business process, no forms to be created, no minions to enter data into them? Think of a consulting geologist, a lawyer, a forensic accountant, a political strategist, a consulting engineer: they are swamped with data. A professional photographer could easily have upwards of a million photos to track. An author has thousands of document references. What general purpose tool can they use to keep track of data?
There is no process, they don't need anything programmed, they don't need any forms, they just need tools to manage data.
If you do this the way most organisations do it -- mainly with Excel -- you wind up with a tangled, unmaintainable, error-and-duplicate-laden shared-via-email-and-maybe-Sharepoint mess. If you do this purely with conventional application development tools (like C#, Java, VB and various Web frameworks, but I also include Access, Sharepoint, etc. in this set), you (or the developers in the IT department) spend a day or week or month on step 2 ("make a form or small application to simplify data entry") whilst some power user impatiently email-launches a series of badly-written spreadsheets to do the same thing and you're back to the Excel problem.
I'm making a better way to rapidly handle the ongoing amorphous intermingling of ad-hoc app dev / data crunching / day-to-day data management that tends to be characteristic of daily administrative work in every organisation. It will suit me on the (mainly) application development end (where I earn coin as an external consultant, soon[1] using my new "datasheet" tool to amplify data-oriented Java programming and data crunching), but it will also hopefully suit power users (who minimally have some coding ability, if only simple expressions) on the data crunching and day-to-day data management side.
Yes, I understand now your definition "you are the customer", but it's the developer you. My customer is the professional drowning in data, looking for a better mousetrap than Excel.
--
[1] Given an as-yet undefined value of "soon".
Do you anticipate an early pre-pre-alpha any time soon?
Quote from dandl on August 12, 2019, 11:13 amQuote from Dave Voorhis on August 12, 2019, 10:01 amQuote from dandl on August 12, 2019, 12:42 amI may have misunderstood: when you say you are your own customer, did you mean the developer you, but still making app things for other people to use?
Where I see the gap is for a product similar to Excel, Word, PowerPoint, System R, AutoCad, MathCad, Mathematica, Blender and a myriad of others: tools for the professional user, not the professional developer. Tools to get stuff done, where the stuff is (relational) data, not code.
[As I wrote that I realised: what about all the non-relational data: key-value, graph, XML-ish? Later.]
Per a post I made above, whilst there's a clear distinction in job titles between various forms of user and professional developer, I don't think there's necessarily a clear distinction between what power users and programmers do. In a typical organisation, it's common for some combination of users/programmers to create a spreadsheet to hold some data, make a form or small application to simplify data entry or provide some ancillary value, pass that wee application to someone to fill in more data, get it back and do some processing to get results, send it to someone else to amend data in a column based on the results, import data from a database/CSV/spreadsheet/etc. to join with the results, create another form to fill in more data, send it to someone to update that data, get it back and release it as an application because a business process is developing around it, implement three new forms to handle a new requirement, rinse and repeat, etc.
I rather think you're missing my point. Yes, such things happen. Not any place where I work, but somewhere. Set them aside.
Have you never worked in a professional consulting environment where highly skilled people use a range of tools of their own choosing, and do none of the above? Where there is no business process, no forms to be created, no minions to enter data into them? Think of a consulting geologist, a lawyer, a forensic accountant, a political strategist, a consulting engineer: they are swamped with data. A professional photographer could easily have upwards of a million photos to track. An author has thousands of document references. What general purpose tool can they use to keep track of data?
There is no process, they don't need anything programmed, they don't need any forms, they just need tools to manage data.
Yes, I'm familiar with specialist data-centric businesses. The generalisation of what they do is now sometimes (mis?) labelled "data science", though they've been doing what they've been doing for many decades and some of their favourite tools -- like SAS -- have been around since the 1960s.
They tend to use one or more general purpose data-crunchers like SAS, SPSS/X, Tableau, Alteryx, and KNIME; plus Excel, various SQL DBMSs, (more recently, and increasingly) Python, along with a number of specialist industry-specific packages. For example, I know a consultant engineer for the automotive industry who used (he's working on a PhD now) a commercial system -- XML document based -- designed for capturing and querying engineering requirements. You can often find advertisements for them in industry publications.
If you do this the way most organisations do it -- mainly with Excel -- you wind up with a tangled, unmaintainable, error-and-duplicate-laden shared-via-email-and-maybe-Sharepoint mess. If you do this purely with conventional application development tools (like C#, Java, VB and various Web frameworks, but I also include Access, Sharepoint, etc. in this set), you (or the developers in the IT department) spend a day or week or month on step 2 ("make a form or small application to simplify data entry") whilst some power user impatiently email-launches a series of badly-written spreadsheets to do the same thing and you're back to the Excel problem.
I'm making a better way to rapidly handle the ongoing amorphous intermingling of ad-hoc app dev / data crunching / day-to-day data management that tends to be characteristic of daily administrative work in every organisation. It will suit me on the (mainly) application development end (where I earn coin as an external consultant, soon[1] using my new "datasheet" tool to amplify data-oriented Java programming and data crunching), but it will also hopefully suit power users (who minimally have some coding ability, if only simple expressions) on the data crunching and day-to-day data management side.
Yes, I understand now your definition "you are the customer", but it's the developer you. My customer is the professional drowning in data, looking for a better mousetrap than Excel.
My initial user is the "developer" me; my long-term users are other developers and technical power users. I'm not targeting non-technical "power users", if there is such a thing.
Do you anticipate an early pre-pre-alpha any time soon?
I do, for an as-yet unspecified value of "soon". Y'all will be the first to know when I release something worth trying.