Episode 4: Dan Bricklin Rejects Adam Green's Original Demo Plan
00:00 Adam: Intro to episode 4.
00:29 Dan: Overview of Dan's philosophy of demos.
04:15 Dan: Experiments with a possible To-Do demo app.
05:35 Selwyn: Initial goals of Alpha's product were business apps.
06:03 Selwyn: Some mobile apps aren't meant for Alpha, like Angry Birds.
06:36 Selwyn: Standard business apps have moved to mobile, and that's where Alpha shines.
07:14 Adam: How can we get to a minimal mobile app (D1) fast that makes people go "Wow"?
08:06 Adam: Should the first demo use a database?
08:29 Dan: You are hiding the real Wow of Alpha when you don't use a database.
10:09 Adam: Mobile apps call for a new type of demo that goes beyond the invoice example.
10:43 Dan: We've always started with a known database in our first demos.
11:36 Adam: A demo that builds a database app will take too long.
11:47 Dan: We'll solve that problem soon.
13:23 Adam: Alpha is a moving target.
13:42 Dan: We need to look at the use cases of different devices.
14:36 Adam: Maybe the To-Do was too low a starting point.
14:50 Dan: I have a nice To-Do app built, but it isn't the best starting demo.
15:15 Adam: We can use a database, but Northwind is not best for a mobile app.
15:48 Dan: We use Northwind, because it is a known database.
16:27 Dan: Can we build a new standard database?
16:47 Selwyn: Many users understand the Northwind schema.
17:19 Dan: Adam is right that we need a sample app and database that looks cool for mobile.
18:18 Adam: A new database should be our next goal.
00:00 Adam: Welcome to Episode 4 of "Adventures in Alpha Land." I'm Adam Green, your host for this episode.
00:08 In Episode 2, I talked with Dan Bricklin and Selwyn Rabins about my goal for a standard set of demo apps for Alpha Anywhere. I wanted a demo that could make people go, "Wow!" about Alpha in just a few minutes. Since then, Dan has been experimenting with several starting demos. Today, he reports on his conclusions.
00:29 Dan: This is going to be more discussion about demos, and I have some philosophy about demos. That then brings up philosophy of Alpha, and we can discuss that a bit, about which demo we should use for what.
00:50 There is the "Wow!" of what we make easier type of demo. Another type of demo is the "learn our way of building," demo. This is a demo where we say, "Let's teach you how to use our system."
01:05 You have to understand how to build something to hold...in the old days, it was what you type in and the function definition, and then, how to compile it and how to run it. That was popularized with the "Hello World" demo.
01:23 The Hello World demo was one where we're just saying, here's how you can get some output. Here's how you get a program running. Here, you can understand that there is the beginning and there's an end and here's how statements are written, etc.
01:39 That's really useful if you want to take that step-by-step, we'll say, "We'll build something. We start with this." It's not at all interesting, but it's the first building block, the scaffolding of putting together an application, and then we'll build it out.
01:54 One of the first things I did was, I took the MVC type, to-do demo, a common one that I found on the web and that had examples running, and tried to implement as close to the same thing using Alpha.
02:15 I was able to do that. But what I realized is, that when you think about it, when you take a development system that was built as an alternative to other development systems.
02:27 They all are. We started with machine language, and we've had all sorts of other things since. For each of them, the system is designed to make certain things a lot easier than the other systems that you had, to emphasize that this is something that we specialize in making really easy.
02:50 We may say that other things we're willing to be just as hard as they used to be. Some things we may say, we're making harder than the other system, or maybe even impossible.
03:03 Then, there's a third type of demonstration that people build, which is building a reference application, which highlights the difference between different development systems.
03:17 It isn't necessary to show off what you're good at or bad at, because depending on what the reference application is, your system may have been not built to make that any easier. In fact, it may have been built to make that harder.
03:29 Sometimes, to help people learn the differences once they know one system and they want to compare it to others, is that you build this reference system.
03:40 If you're having to build the same type of system, let's say, you're building a system that all of them use mice and keyboard, and they all have the same type of input and the same type of display, and it's just some other organizational thing, then, it's useful to have that same exact thing re-implemented with multiple.
04:01 It's a good way to start, because often that will show you the same thing as the second way of how to build in the process. Hopefully, you'll see some! "Wows," but maybe not. It depends on which reference.
04:15 With the to-do application, I got the feeling that, first of all, I was taking an application designed for a mouse and keyboard, and trying to implement it in the metaphor of a touch device, which is somewhat different.
04:35 In fact, a lot of the demos we had, had hover was being used, and of course, hover doesn't exist on the iOS devices, and even on the Android devises. It didn't seem to be built for it. In fact, if I was using Alpha, I would use different types of things for Alpha that were optimized around keyboard and mouse and I would have built it differently.
4:58 What I realized is, we have to decide here. First of all, which particular demos are we doing? We should do a "Wow" demo. We should do a "learn to build our way" demo, and we also may want to do some, "Here's how you do a reference app," just for your own purposes.
05:17 We should be clear about it, but before we can do that, this brings up the question to ask Selwyn, since Selwyn is the one most involved in this. What was Alpha Five, and then, Alpha Anywhere, what was that designed to make easier?
05:55 Selwyn: They were applications that help companies run their business. The meat and potato applications that people run to manage payroll and inventory and orders, and manage employee records, etc.
05:52 Dan: You wouldn't build a spreadsheet in it.
05:53 Selwyn: You wouldn't build a spreadsheet in it. You couldn't build a spreadsheet in it, it's just not intended for that purpose. The same concept holds now in the mobile world.
06:06 There are many examples of mobile apps that we're all familiar with, that we've seen on our mobile devices, that aren't candidates for being built in Alpha Anywhere, because those apps are fairly light on database interactions, and they focus mostly on, "Gee, whiz, UI" experiences in the mobile device.
06:33 Whereas, the standard business applications that people use to run their businesses, now those apps have moved, once again, from standard web browsers into mobile devices.
06:51 That's where "Alpha Anywhere" shines and that's really where it's intended to be used. You wouldn't try to build "Angry Birds" in Alpha Anywhere, it's just not appropriate. But you would try to build your expense reporting system for a mobile phone in Alpha Anywhere.
07:14 Adam: One of my goals was that you get to a mobile app fast. That you say, "Here are the minimal number of steps to actually create something that runs on a mobile phone and looks like a mobile app."
07:31 With the desire to make that as few steps as possible to get to that "Wow!" as early as possible, I set up the artificial constraint of no database in that very first demo, what I'm referring to as D1.
07:50 The other artificial constraint is to be able to allow either D1 or some extension to it to be used as a comparison with the competing mobile development systems. Many of those mobile development systems either have no direct connection to databases, or work with other tools, other back-end systems, to get to a database.
08:18 If you put a database in the first demo, by definition a lot of the competitors are knocked out. That may seem like a good thing, but what's the point of a comparison that you can't compare things to?
08:29 Dan: What you're saying is that the "Wow!" of Alpha, which is how easy it can work with business data, is something that we would not show in the demo, and the part that we have right now, that we're still optimizing, which is the initial setup of a simple mobile app.
08:58 You, say, start with the template that we have for the simple mobile app and you're done. You have something where you can swipe between a few cards on the screen.
09:09 Adam: And do those things in the cards, such as the to-do list.
09:13 Dan: The to-do list happens to be a type of application that was tuned around a keyboard, mouse type of system, with a certain type of lists and certain types of interactions with the in place editing and certain types of how you interact with the data.
09:38 Those particular ones that are used are not necessarily the things that were optimized at this point in Alpha. By definition, I think if you take the to-do, you're saying I'm doing a reference app that Alpha actually may have as its, we don't do this, as well as we do other things. We may do it worse than somebody who's been tuned to that. We were tuned for something, to do a "Wow!" of, something that you're not even showing.
10:09 Adam: But there's two kinds of "Wows." In the earlier versions of Alpha, it was, "Wow. I can build an invoice with no programming or virtually no programming.
10:23 I could have master-detail data entry systems which normally takes a lot of back end relational programming, and get there without that programming or with very little. That was a database "Wow!"
10:36 Dan: Right, and we're going to do the same thing for mobile.
10:38 Adam: With later demos, we will get to the database, but...
10:43 Dan: What I'm saying is, with Alpha, the initial demo that we've always shown people was to say we'll start with a known database, that we all know in the database world. We'll show you how we can take that existing database, which is a very common need of the people who are looking to move to mobile, who are elsewhere.
11:09 We're showing you how you can take that existing database and have a mobile application in no time, that supports it, with all the details and sub-details and stuff like that. That's a real "Wow!" That's what we optimized for. We didn't optimize for building the to-do list, for example. In fact, the particular to-do list UI, we didn't optimize for at all.
11:36 Adam: But a demo that builds a database application, no matter how simple it is, is going to be 15 minutes, 20 minutes.
11:48 Dan: Not when we're completed with what we're working on right now. When we do an Alpha demo of Alpha Anywhere, or the old Alpha Five, but especially Alpha Anywhere, demonstrating for a browser-based application, in a few minutes we go from an existing database, which was off the shelf, in this case it's Northwind.
12:14 Filling out a few dialogues, following some wizards, and viola. In a few minutes, you have a complete application that lets you search for things, make edits, update, etc, and filter whatever. That's what Selwyn chose.
12:34 We're working to get the same type of a demo of a fully mobile, disconnected application, built the same way. In fact, Selwyn has a demo that can build off of that database, can build a laptop disconnected application in just a few minutes, that's very complete. It's a real "Wow!"
13:02 For to-do, we don't. Because to-do, especially, without a database, a lot of the things that we make easy, the use of existing data and displaying it. The things that we make trivial to formatting a lot of that stuff, just don't come into play.
13:24 Adam: There are two problems. One is this sort of Heisenberg issue, where the more we look at the potential of a database, the more we change the product to make that demo easier. That's a never-ending process, so I'm not sure where you start.
13:42 Dan: One thing to do is to look at the uses that we think people are going to be making of their devices.
13:51 Let's take a tablet. One of the big uses of a tablet in business seems to be for use in field people. People who cannot use a laptop or a desktop machine to do their stuff, who are currently using paper and then going back to a laptop for data and entering it into the system.
14:12 To connect them either live to the data, or with this connected to be able to do it later, perhaps. To access data that they need, and be able to update some of that or enter new data that's then shared by other people. That is one of the big uses that we see.
14:37 Adam: I'll accept that. It may be the to-do as a starting point, might have been aiming too low, and ironically, have made the project harder to actually implement.
14:49 Dan: I have a really nice one, that uses Alpha, but it doesn't play to Alpha's strengths.
11:56 It's easier to do many of the things in it than it is in other systems, but it still involved me needing to know how to program. It's not just pushing a few buttons and a few dialogues that were clearly designed to facilitate that particular type of application.
15:16 Adam: But where I still push back, and we definitely have to wrap this up, is using Northwind, the standard existing Alpha demo, as the demo for a mobile app.
15:30 Because I can understand the field data entry, data collection models, especially, data collection. I have a real problem imagining someone filling out a full invoice with line items, details and customers, on a tablet or a phone.
15:48 Dan: I completely agree with you except for the salesperson who is there looking at old data, and that gets into the issue of how much can you store locally on the machine.
16:00 I think the one reason that we use Northwind so far is, and it doesn't mean we should use it going forward, is that it's known by a lot of people, they already understand the schema very well, and it's been in a lot of examples, we don't have to teach that.
16:16 The other is, it has been constructed with so many interesting variations and stuff that it helps really shake down any application you build with it. If we could build another database that was more appropriate for this type of stuff, that could be our standard that we do everything off of, that would be wonderful.
16:37 Unfortunately, we don't have one of those yet. If you would love to build it, there's no reason to use Northwind otherwise. Except, Selwyn, if you can think of something?
16:47 Selwyn: The only reason that we've used Northwind for demos is that a large number of users already understand the schema, this is what you just said.
17:01 When you're looking at a demo of an application, if you don't understand what the schema is behind the application, then a lot of what's going on in the app, you don't really get it. If you understand the schema, then, that's a huge part in understanding what the app is doing.
17:20 Dan: But I think that Adam is right in that if we're trying to build applications that are motivating and interesting about being mobile apps, we really have to be building our sample apps that look like cool, "I could use this. I need this." mobile apps.
17:37 Therefore, maybe what this is helping us understand is, we have to come up with a reference database to use for some of our demos, which helps to think about where the demo will go by the end so that this database is relatively complete, though when we start we may just use a subset of it, maybe we don't need to do that.
18:04 But Adam, this gives you an interesting challenge, to figure out what would be the end application, or parts of them, that we'd end up with. What database would we have, and can we pre-populate one of those.
18:18 Adam: Why don't we pick it up on the next podcast? Thank you, guys. This has been really interesting.
18:26 Dan: Thank you, Adam.
18:27 Selwyn: Thank you.