Quote from Dave Voorhis on August 10, 2019, 7:38 am

Interesting approach, targeting "... someone with a degree of technical skill but no specific programming ability."

I've gone for almost the opposite, specifically targeting programmers, not non-programming power users.

The zero-code notion unquestionably has appeal. I've seen products in this arena since the late 1970's. Most recently, I'm getting near-constant ads on LinkedIn for one called "Betty Blocks". A few months ago I was high-pressure salesmanned by a sales rep from wanting to teach classes in his company's zero-code product. I said no, quite bluntly. I told him I didn't see any theoretical or practical value in it, and no reason to believe his company's product would be any more successful than myriad others.

Even COBOL notionally started out as a programming language for non-programmers.

Yet, we don't seem to be any closer to that ideal today than in the 1950's. Every solution that's non-technical enough for non-programmers to use turns out to be insufficiently capable, or else it's capable enough but turns out to need programmers.

Quote from dandl on August 10, 2019, 8:18 am

Quote from Dave Voorhis on August 10, 2019, 7:38 am

Interesting approach, targeting "... someone with a degree of technical skill but no specific programming ability."

I've gone for almost the opposite, specifically targeting programmers, not non-programming power users.

There was quite a boom in products targeting the 'not very good programmer' market back in the early days of minicomputers, and again PCs. The rationale was the super-coders were making the big bucks on IBM mainframes, and these were products for everyone else. That included 4GLs, 'paint by numbers' form fillers, a number of genres. I know the market well, since we had a 4GL and did well from it. But no longer, it seems.

I suspect the main problem is the rapid change in tech. There never was a meaningful 'dBase for Windows', and each generation since only seems to last about 5 years before becoming legacy. The web in 25 years has had at least 4 or 5 really different ways of building apps. Mobile in 20 years nearly as many (anyone remember Palm?). You can't abstract away the hard parts of programming if they keep changing so fast. Maybe some time, just not now.

The zero-code notion unquestionably has appeal. I've seen products in this arena since the late 1970's. Most recently, I'm getting near-constant ads on LinkedIn for one called "Betty Blocks". A few months ago I was high-pressure salesmanned by a sales rep from wanting to teach classes in his company's zero-code product. I said no, quite bluntly. I told him I didn't see any theoretical or practical value in it, and no reason to believe his company's product would be any more successful than myriad others.

Even COBOL notionally started out as a programming language for non-programmers.

Yet, we don't seem to be any closer to that ideal today than in the 1950's. Every solution that's non-technical enough for non-programmers to use turns out to be insufficiently capable, or else it's capable enough but turns out to need programmers.

The aim of Naxl is to start out with something visually obvious, just like Excel. Start with tables of data, and a way to link them together. Add a table, add the columns you need, format them the way you want, add computed fields as simple expressions, just like Excel. Add some expressions to validate data input if you must. Now you have a 'Window on Data', with no code, just a few expressions. Surely anyone can do that?

Then think about plug-ins or extension classes to add custom logic, but only as an after-thought. It should work OOB.

As an aside, I still haven't decided on the tech to use. I prefer C#, JS rules the web, but there is a good argument to use Java and target the desktop initially. What do you think? Is there a good-enough table widget out there to do the heavy lifting?

Quote from Dave Voorhis on August 10, 2019, 9:24 am

Quote from dandl on August 10, 2019, 8:18 am

The aim of Naxl is to start out with something visually obvious, just like Excel. Start with tables of data, and a way to link them together. Add a table, add the columns you need, format them the way you want, add computed fields as simple expressions, just like Excel. Add some expressions to validate data input if you must. Now you have a 'Window on Data', with no code, just a few expressions. Surely anyone can do that?

That's essentially the approach I've taken (so far) with my (call it) Datasheet.

Unfortunately, my experience from the admin/management team where I last worked is that "just a few expressions" is beyond the ability of the majority of users, requiring either significant help from an (invariably overworked) office "power user" -- who has often reluctantly become essentially a junior programmer working solely on spreadsheets and MS Sharepoint -- or the IT department. Often as not, the few expressions are never incorporated: calculated values are manually computed on a pocket calculator or calculator app, or one-by-one in a cell in a corner of the spreadsheet, or by hand on a paper printout of the spreadsheet.

After my own personal use (which is my primary goal) that power user and the IT department are my target market.

Quote from dandl on August 10, 2019, 8:18 am

Then think about plug-ins or extension classes to add custom logic, but only as an after-thought. It should work OOB.

OOB?

Quote from dandl on August 10, 2019, 8:18 am

As an aside, I still haven't decided on the tech to use. I prefer C#, JS rules the web, but there is a good argument to use Java and target the desktop initially. What do you think? Is there a good-enough table widget out there to do the heavy lifting?

It depends what UI toolkit you target. I initially considered JavaFX but didn't find anything pre-built that I liked, and the whole framework seemed -- to me, at least -- rather immature. I've gone with SWT which is capable and mature and provides native look-and-feel on Windows, Mac, Linux, and via RAP (Remote Application Platform), the Web.

There are various commercial grid widget offerings, but I didn't find anything that does what I want and provides source code.

Nattable is probably the best-known and most capable free-and-open-source table widget (it's part of Eclipse's "Nebula" project to create a rich set of SWT widgets), but it doesn't support RAP. So I'm using the Nebula Grid widget, which has turned out to be fine particularly as the grid itself is not really the key ingredient. The key ingredient is, I think, is not so much the grids themselves but how grids are incorporated into the overall environment. But that's still very much an experimental work-in-progress.

Quote from AntC on August 10, 2019, 10:27 am

Quote from Dave Voorhis on August 10, 2019, 7:38 am

...

Even COBOL notionally started out as a programming language for non-programmers.

Yet, we don't seem to be any closer to that ideal today than in the 1950's. Every solution that's non-technical enough for non-programmers to use turns out to be insufficiently capable, or else it's capable enough but turns out to need programmers.

I disagree: Excel (esp with VB scripting) is easily sufficiently capable. And there's plenty of non-programmers (accountants, data analysts) exploiting all of the power. [Perhaps the context I'm used to explains my observations being different: a management consulting practice within a firm of Chartered Accountants.] The reason it needs programmers is to tame the chaos arising from undisciplined poke-formulas-everywhere.

I agree with the later comments that insufficiently capable users (non-programmers) would rather calculate off-cell/off-spreadsheet and poke the results. With luck they get sufficiently far to prove the concept, then call in my firm; typically because somebody's made some business case or financial representation based on bodged calculations.

Quote from Dave Voorhis on August 10, 2019, 10:43 am

Quote from AntC on August 10, 2019, 10:27 am

Quote from Dave Voorhis on August 10, 2019, 7:38 am

...

Even COBOL notionally started out as a programming language for non-programmers.

Yet, we don't seem to be any closer to that ideal today than in the 1950's. Every solution that's non-technical enough for non-programmers to use turns out to be insufficiently capable, or else it's capable enough but turns out to need programmers.

I disagree: Excel (esp with VB scripting) is easily sufficiently capable. And there's plenty of non-programmers (accountants, data analysts) exploiting all of the power. [Perhaps the context I'm used to explains my observations being different: a management consulting practice within a firm of Chartered Accountants.] The reason it needs programmers is to tame the chaos arising from undisciplined poke-formulas-everywhere.

Perhaps there's a bit of a labelling/definitional issue here, methinks. Are the accountants and data analysts really non-programmers? Or are they specialist programmers trained in accounting and data analysis? Is fully exploiting a spreadsheet package a non-programming (but presumably technical) task? Or is it spreadsheet programming?

There's really a continuum here rather than a discrete categorisation, ranging smoothly and continuously from non-programmer (what do you mean "expressions"?) to semi-programmer (expressions and even complex spreadsheets/SQL/bit of VB is fine; Java/C# no, C/C++ definitely not), to "full" programmer (if it's programmable, I'll program it) with everything in between. Likewise for "no code" to "programming language" environments; a continuum rather than categories. The endpoints are clearly distinct, but everything in between is blurry.

Quote from dandl on August 10, 2019, 11:22 am

Quote from AntC on August 10, 2019, 10:27 am

Quote from Dave Voorhis on August 10, 2019, 7:38 am

...

Even COBOL notionally started out as a programming language for non-programmers.

Yet, we don't seem to be any closer to that ideal today than in the 1950's. Every solution that's non-technical enough for non-programmers to use turns out to be insufficiently capable, or else it's capable enough but turns out to need programmers.

I disagree: Excel (esp with VB scripting) is easily sufficiently capable. And there's plenty of non-programmers (accountants, data analysts) exploiting all of the power. [Perhaps the context I'm used to explains my observations being different: a management consulting practice within a firm of Chartered Accountants.] The reason it needs programmers is to tame the chaos arising from undisciplined poke-formulas-everywhere.

Excel has many strengths, but there are things it does badly if at all.

1. Maintaining a table by adding/deleting/modifying rows, without collateral damage to formulae and formatting.
2. Maintaining linked tables, without collateral damage.
3. Maintaining totals and sub-totals in tables, without collateral damage

These are exactly the things a databasespreadsheet (or NAXL) will do in sleep.

I agree with the later comments that insufficiently capable users (non-programmers) would rather calculate off-cell/off-spreadsheet and poke the results. With luck they get sufficiently far to prove the concept, then call in my firm; typically because somebody's made some business case or financial representation based on bodged calculations.

My aim is to target the power user who is not (by job description) a programmer. They will happily arrange things on a page and write formulae, but struggle with the discipline of writing any kind of imperative logic. They will create spreadsheets for minions, and correct mistakes in what they get back. And they will delegate to expert programmers when they need to. They are a big market, quite large enough for my purposes.

Quote from dandl on August 10, 2019, 1:22 pm

Quote from Dave Voorhis on August 10, 2019, 9:24 am

After my own personal use (which is my primary goal) that power user and the IT department are my target market.

I'm only aiming to satisfy myself and the power user. IT has its own agenda.

Quote from dandl on August 10, 2019, 8:18 am

Then think about plug-ins or extension classes to add custom logic, but only as an after-thought. It should work OOB.

OOB?

Sorry. Out of the box.

So I'm using the Nebula Grid widget, which has turned out to be fine particularly as the grid itself is not really the key ingredient. The key ingredient is, I think, is not so much the grids themselves but how grids are incorporated into the overall environment. But that's still very much an experimental work-in-progress.

Then I'm losing the thread. In Excel, the UI is 100% grid. There are tabs, menus, dialog boxes, charts, but everything revolves around the grid. What overall environment did you have in mind?

 

Quote from Dave Voorhis on August 10, 2019, 2:03 pm

Quote from dandl on August 10, 2019, 1:22 pm

So I'm using the Nebula Grid widget, which has turned out to be fine particularly as the grid itself is not really the key ingredient. The key ingredient is, I think, is not so much the grids themselves but how grids are incorporated into the overall environment. But that's still very much an experimental work-in-progress.

Then I'm losing the thread. In Excel, the UI is 100% grid. There are tabs, menus, dialog boxes, charts, but everything revolves around the grid. What overall environment did you have in mind?

I consider that to be one of the flaws of Excel, forcing everything into a grid when there are things that do not benefit from -- or made worse by -- a grid.

I propose multiple views: conventional spreadsheety grids for viewing/editing data; a similar-but-different grid for creating data-entry forms; a graphical icons-on-strings query/expression builder (nabbed and re-worked from Rel); text editors for editing Java code (nabbed and re-worked from Rel), trees for managing hierarchies of document contents and code packages (again, from Rel); plus maybe integrate a preexisting report builder like BIRT, maybe a drag-n-drop document assembly area (for making forms, reports, and particularly dashboards) somewhat inspired by desktop publishing, and maybe a zoomable graphical "model" for overall content structure in addition to the aforementioned trees.

I'm still considering whether each of the last three items are necessary, nice, or useless.

Quote from dandl on August 11, 2019, 1:07 am

That'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.