I was thinking about basic CRUD applications to start. I think it would be valuable for a business to be able to build a small, basic CRUD application to manage certain processes like QA, or any other basic data-keeping that's needed - in situations where ready-made products just don't fit the bill.
Technically you can build basic CRUD stuff using Xcode and Interface Builder on Mac OS X:
1. Design your GUI using Interface Builder
2. Design your Core Data model in Xcode.
3. Connect the two using Bindings in Interface Builder.
It will be very very basic, but you can get something built without writing a single line of code. Ideally find some sort of tutorial that steps you through how to do every step, especially configuring and connecting Bindings. You won't truly understand everything, and the only way to do so will be to take the next step and learn C/Objective-C and the Cocoa API.
Business-oriented databases generally have this kind of feature. I believe both MS Access and FileMaker have drag-and-drop-style form builders allowing a non-programmer to create a purpose-built user interface to query and update the database.
Yeah Access was the closest think I could think of. But for what I'm picturing, that's too complicated - I don't want the end-user to see or think about the database at all. The end-user should basically drop and drag things, then click a button that says "create application" and it spits out your app.
The name for the activity you describe is programming. Just because you've not typing lines of code doesn't mean you're not programming.
Meanwhile, you need to think about why people like spreadsheets. Yes, they show you all your data on a big stupid sheet and force you to look at it, but that's a feature, not a bug. People don't collect data because pressing buttons is fun. They want to see their data again. Indeed, not being able to relocate their hard-won data is their worst nightmare, so it is reassuring to see it right there and know that you can find it. It's easy to find data in a spreadsheet: Just scroll around until you see it. It's got to be right there on the page: It's a spreadsheet. Even a nonprogrammer can navigate a simple spreadsheet.
It's even easy to change the data. You see a number you don't like, you type over it.
If you want something with better organization or navigation than a simple spreadsheet, you'll need, at the very least: Forms to type the data in, and reports to get the data out. But presumably your forms will need carefully-chosen field types, and validation against app-specific criteria, and maybe even record-to-record relations, or why wouldn't you just use a spreadsheet? And the reports will have to be fancier than just a big table, or why wouldn't you just use a spreadsheet? And when you design these forms and records and relations and reports... you'll be programming.
The reason I would not choose a spreadsheet for this idea is for a cleaner layout. I think a basic form with boxes and labels, where the other data is hidden, would be more user-friendly. A spreadsheet has data all over, and that can be distracting to see and navigate around - for me, anyway. That's my preference.
Lots of spreadsheets are eye-bleedingly bad. It doesn't have to be that way. Some principles I use when trying to improve hideous spreadsheets:
1) The main body of the data should fit on one page. In many cases, it can be made to fit, you just need to reorganize some of it and tweak sizes of boxes, use some reasonable abbreviations, etc.
2) Try to keep it to 7 colors (though this rule can be bent a smidgeon by going one shade darker for emphasis without really introducing a totally new color).
3) "Whiting out" (though beige, gray or taupe can be better choices than white) the background boxes can go a long way towards making a spreadsheet less torturous to look at.
4) Going one font size up and adding bolding can be plenty of emphasis. You really don't need anything of size 72 lettering just because it's a title or some such.
(I'm sure you don't personally care. And I'm not trying to change your mind. Maybe I just needed to say it for myself.)
Microsoft Access is probably the best fit for you.
However, beware the danger of ending up with your business fundamentally built on Access. Many products make it easy to program, there is no product that makes programming easy. Just underneath the candy shell, the horrifying Turing chaos waits for you the same as any "real" programming environment, and many is the person who has inadvertently released an Elder God from his tasty confectionery prison to consume their business whole.
I'm being a bit flowery, but I am serious. It's happened many times and I've seen it myself once. Use the tool responsibly; the poky bits haven't been taken out, just moved around a bit.
I'm afraid there are no shortcuts in this business. Programmers/developers are hugely undervalued because people without similar skills have no idea just how difficult it is to build systems.
You should hire someone smart to do this work for you, instead of trying to do it by yourself. Given that your requirements are vague, I would recommend you pay someone a few hundred quid/dollars to talk to you for a day and figure out what technology you're going to need to use. Then you will be in a good position to hire.
If you try and do this by yourself there is a very high chance you will do it wrong. Worst case scenario is that you don't even know it's wrong and it just keeps giving you the wrong data forever.
I worked with an insurance client once who had been overpaying bonuses for years without knowing. You don't want to be that person - hire a programmer. They are cheap, all things considered!
You may want to check out http://wufoo.com for some data collection tasks.
Also, I recommend trying out a hosted wiki and Google Docs. Having a shared Google Docs spreadsheet will probably be more functional than anything you can build without actually programming.
I believe the nature of software prevents such an application from existing. I would cite the complicated nature of all parser-generators as partial proof.
WYSIWYG HTML generators may be as close as it gets, and that doesn't end up creating much in the way of "code".
We're working on a framework we hope to expose to our customers for just this purpose. It'll be made up of modules you can add and a GUI for field/form customisation. A bit like Microsoft Access but web based, is that what you had in mind?
Somewhat, but easier to use than Access. I was thinking that after learning the tool, the end-user should be able to create a basic CRUD application with one or more workflows/screens in a few hours, tops.
Do you have any information about your framework? I'm interested to know more.
The closest thing I've heard of recently would probably be VisualStudio LightSwitch. I've never used it and am pretty skeptical about this sort of thing in general from experience with MDA tools in the past, but it's probably worth a look.
Apple/NeXT used to have enterprise object framework.
There's a video of steve jobs building a fairly complex DB app without a single line of code, including joins.
Requires nothing more than a Google/Google-Apps user account to get going.
You can define Entities ("table"/"sheets") and Attributes ("columns"/"fields") to get working with your database app within a few minutes.
Integrates with Google Contacts (import/upload), Google Docs (attach docs to database records), Google Maps (mark and search for records based on geographic location). Google Calendar (export events/tasks-like data) and email integration are coming up later.
- Authorization Profiles for fine grain access control up to field level.
- Custom Views to filter data matching your criteria.
- Custom Actions for single click edits.
- Automated Audit of all write operations
- Bulk Export & Import of data as CSV files.
- Support for drop-down choices,
look-up fields (references) and
image fields (with auto thumbnails for list view)
..and more.
COBOL was the earliest effort I know of to allow non-programmers to create applications. Its English-like syntax allowed managers and business analysts to describe what they wanted the computer to do without programmers' help. Or such was the belief/hope circa 1960.
I think the desire to program without programming is somewhat misguided. It's great to avoid churning out boilerplate code, and it's great not to need to remember lots of arcane interfaces, but programming, even in the most WYSIWYG DWIM system, still requires the ability to mentally model how the machine interprets its instructions and to write (click, draw, gesture, vocalize) instructions that solve the right problem.
29 comments
[ 4.7 ms ] story [ 79.0 ms ] threadMeanwhile, you need to think about why people like spreadsheets. Yes, they show you all your data on a big stupid sheet and force you to look at it, but that's a feature, not a bug. People don't collect data because pressing buttons is fun. They want to see their data again. Indeed, not being able to relocate their hard-won data is their worst nightmare, so it is reassuring to see it right there and know that you can find it. It's easy to find data in a spreadsheet: Just scroll around until you see it. It's got to be right there on the page: It's a spreadsheet. Even a nonprogrammer can navigate a simple spreadsheet.
It's even easy to change the data. You see a number you don't like, you type over it.
If you want something with better organization or navigation than a simple spreadsheet, you'll need, at the very least: Forms to type the data in, and reports to get the data out. But presumably your forms will need carefully-chosen field types, and validation against app-specific criteria, and maybe even record-to-record relations, or why wouldn't you just use a spreadsheet? And the reports will have to be fancier than just a big table, or why wouldn't you just use a spreadsheet? And when you design these forms and records and relations and reports... you'll be programming.
1) The main body of the data should fit on one page. In many cases, it can be made to fit, you just need to reorganize some of it and tweak sizes of boxes, use some reasonable abbreviations, etc.
2) Try to keep it to 7 colors (though this rule can be bent a smidgeon by going one shade darker for emphasis without really introducing a totally new color).
3) "Whiting out" (though beige, gray or taupe can be better choices than white) the background boxes can go a long way towards making a spreadsheet less torturous to look at.
4) Going one font size up and adding bolding can be plenty of emphasis. You really don't need anything of size 72 lettering just because it's a title or some such.
(I'm sure you don't personally care. And I'm not trying to change your mind. Maybe I just needed to say it for myself.)
However, beware the danger of ending up with your business fundamentally built on Access. Many products make it easy to program, there is no product that makes programming easy. Just underneath the candy shell, the horrifying Turing chaos waits for you the same as any "real" programming environment, and many is the person who has inadvertently released an Elder God from his tasty confectionery prison to consume their business whole.
I'm being a bit flowery, but I am serious. It's happened many times and I've seen it myself once. Use the tool responsibly; the poky bits haven't been taken out, just moved around a bit.
You should hire someone smart to do this work for you, instead of trying to do it by yourself. Given that your requirements are vague, I would recommend you pay someone a few hundred quid/dollars to talk to you for a day and figure out what technology you're going to need to use. Then you will be in a good position to hire.
If you try and do this by yourself there is a very high chance you will do it wrong. Worst case scenario is that you don't even know it's wrong and it just keeps giving you the wrong data forever.
I worked with an insurance client once who had been overpaying bonuses for years without knowing. You don't want to be that person - hire a programmer. They are cheap, all things considered!
http://www.microsoft.com/visualstudio/en-us/lightswitch
Also, I recommend trying out a hosted wiki and Google Docs. Having a shared Google Docs spreadsheet will probably be more functional than anything you can build without actually programming.
WYSIWYG HTML generators may be as close as it gets, and that doesn't end up creating much in the way of "code".
Do you have any information about your framework? I'm interested to know more.
http://www.microsoft.com/visualstudio/en-us/lightswitch/
The result is armies of people not qualified to write programs starting creating Notes "crapplications". Now everyone hates Notes.
We still have nothing like it.
http://www.youtube.com/watch?v=j02b8Fuz73A See about 25 minutes in.
Requires nothing more than a Google/Google-Apps user account to get going.
You can define Entities ("table"/"sheets") and Attributes ("columns"/"fields") to get working with your database app within a few minutes.
Integrates with Google Contacts (import/upload), Google Docs (attach docs to database records), Google Maps (mark and search for records based on geographic location). Google Calendar (export events/tasks-like data) and email integration are coming up later.
The web-app can be mapped to your own domain like http://app.yourdomain.com (using Google Apps).
Other features include :
Hope you like it. Feedback welcome.I think the desire to program without programming is somewhat misguided. It's great to avoid churning out boilerplate code, and it's great not to need to remember lots of arcane interfaces, but programming, even in the most WYSIWYG DWIM system, still requires the ability to mentally model how the machine interprets its instructions and to write (click, draw, gesture, vocalize) instructions that solve the right problem.