User Interface Oriented Application Development

User Interface Oriented Application Development

• airwalker2000

  Babak Farahani wrote:

  No, it is really, completely different with InfoPath or Access. The biggest and main different is that in those products, you need to design/develop your database, then create the UI based on it. Please NOTE: What I am talking about is about a different approach in application development. Form generation is not what I do mean by UIOAD. In current development process, the most known approach is to discovering the data model, designing the ERD/Database, business programming and UI developing. UIOAD says, we must look at the software development from another point of view. Start to design what you want to like at the end. I think the nearest concept to UIOAD is RAD development. RAD says you can have some independent objects (for example OCX controls) which help you to design and develop your application rapidly. Think more about the subject and functionality, less about the development, record management and so on. UIOAD says, think about the final product, have a designer/development environment and start thinking and developing simultaneously! I am appreciating all you guys consideration and concern on UIOAD, and I am sure if you help us at UIOAD.org we can make the idea more and more complete and practical. Regards

  
  
  The main problem I see here is that when your database design is UI driven, the database created probably can only serve well the UI that is based on. How about other UI need to be developped later to use the same data Then the database structure may not fit the development of new UIs.
  
  UIOAD is good thinking though. With this approach, you probably need to develop a set of methodologies related to it. One is form design and form relationship design. To increase reusability of the foms and flexibility of UIOAD databases, you will probably promote to make each form representing an entity. Then your approch will be doing FRD (Form Relationship Design) instead of ERD.
  
  Your UIOAD also doesn't fit into the situaion when the databases already exist, and you need to develop UI applications to show data.
  
  It is good that you are thinking of different approaches, because a lot of our development time is spent to retrieve data from some where, either database, or XML file, or flat files and then display the data in some text boxes, combo boxes, etc. Then put updated data back to their storage place. But I will not vote for UIOAD. RDBMS has its problems. Since nowadays software development and design are object oriented, OODB seems more attractive.
  
  
  

• Bunk

  Thanks for your info, but This link (http://www.enformatika.org/data/v16-39.pdf) dosen’t work, can you sendme a different link

  my email is nunez_raul@hotmail.com

  
  

• yog_23

  Don't know what's RDBMS theory. In salesforce.com, it gives you a table of Controling List by Depending List, and you simply highlight the depending value you want to see on a column of Controling value. I think that's the most simplistic way you can get. "How she can create a combo box for listing States and Cities, without writing a simple line." is too far fetched for me. Someone has to define which City belongs to which State, either by developer or a public database like MapQuest. But you know, States and Cities is same accros company.

  I don't know how much automation you want to get. But just make sure it is easy to use and easy to adapt. I have tried Prolog. It sounds cool that it decides how to solve the problem for you, all you need is to ask. But it turns out, for me, telling computer to do something step by step is easier to ask them a proper question to get desired result. Even SQL is getting hard to use because it is not easy to predict a result of a formula and it is really hard to debug when a formula has bug. It is Predictable vs Automation. Simplicity vs Flexibility.

  
  

• hye_heena

  Hello,

  From your example, you should check out this site for CRM. www.salesforce.com

  Not to discourage or anything, but they have an easier way to make a form.

  1. Click Edit Form
  2. Click Add Custom Field
  3. Click Custom Field data type, includes UI data type multi-select pick list.
  4. Fill in Custom Field detail, like values(city names).
  5. Click Save
  6. Click Edit Layout to move fields around the form. Define field is editable. Define field is required.
  7. Click Data dependency to link a pick list to another pick list, like City list is dependent to State list.

  All done. You have a nice form and they manage everything else for you. They have a powerful report tool to analyz your data too. And powerful S control system if you want to define the function in deeper detail. It is not only UI driven, but it is On-Demand which you can customize your application online. And they have AppExchange that you can buy plug-in from 3rd party to do crazy stuff, or you can build plug-in and sell in on AppExchange. They have the full user community and developer community layout.

  If you want to try it, they have trail version or developer version for free.

  
  

• enric vives

  Looks far more complicated than it actually is. Sounds like you are trying to apply a formula to something which is non-complicated but hard. Some people have the ability to create outstanding user interfaces and some people just...don't. No amount of structure or formulation will change that.

  
  
  

• drvsrs

  also, this kind of sounds a bit like some aspects of InfoPath ... or good old Access forms ...
  

• Hugo Soares

  No, it is really, completely different with InfoPath or Access.

  The biggest and main different is that in those products, you need to design/develop your database, then create the UI based on it.

  Please NOTE: What I am talking about is about a different approach in application development. Form generation is not what I do mean by UIOAD. In current development process, the most known approach is to discovering the data model, designing the ERD/Database, business programming and UI developing. UIOAD says, we must look at the software development from another point of view. Start to design what you want to like at the end.

  I think the nearest concept to UIOAD is RAD development. RAD says you can have some independent objects (for example OCX controls) which help you to design and develop your application rapidly. Think more about the subject and functionality, less about the development, record management and so on.

  UIOAD says, think about the final product, have a designer/development environment and start thinking and developing simultaneously!

  About the www.salesforce.com sample, well, it can be an implementation of UIOAD, however, for instance, the State->Cities relation have been defined, probably hard coded be the application developer, lets say form designer. But in UIOAD we are thinking how we can create a development environment that gives the developer to define the mentioned relation without having any knowledge about RDBMS theory! How she can create a combo box for listing States and Cities, without writing a simple line. UIOAD covers all steps in a software product lifecycle, from form generation to workflow management and reporting.

  I know some how what I am talking about is imaginary. That is because as I mentioned before, we think about software development process in the way it is. I invite everybody to think if it can be different to what we learned. Of course, it does not mean we will not have any database, for example. As I promised I will upload an implementation (which is very far from UIOAD, now, but can give you a sense) in next few days.

  I am appreciating all you guys consideration and concern on UIOAD, and I am sure if you help us at UIOAD.org we can make the idea more and more complete and practical.

  Regards

  
  
  

• MikeL.2k

  Hello, do you have a graph for it

  I cannot picture the concept. Maybe a flash animation demo or something to show how it should look and behave. We already have a pretty simple form editor and all that. And some kind of data binding or whatever. How is your concept make the whole thing easier

  
  

• Stephie

  Hi everybody, happy new year!

  I am very sorry if I uploaded the demos I promised by this much latency. By the way, here are two different demos on SITCO eForm, a general form development tool. As a matter of fact at the first time, the application was just a regular form generator, but after a while, we found out we have developed our idea, UIOAD! So, this link shows the application, but this one shows how it can be used as an application development tools to develop general database software based on UIOAD.

  I am very sorry that I could not explain my idea very clear to all. Part of it is the fact all of us compare any new methodology/suggestion to traditional/current ones. Another reason is that I can not explain it, in the way I must. Please check the demos and let me know any question. I guess in this way I can say what I have in mind!

  Regards

  
  
  

• Johnh_avanade

  Thanks for your reply. I was almost getting disappointed! Sometimes I think maybe the idea is that much selfish that nobody do like to think about it. By the way, may you please take a look at this article: http://www.enformatika.org/data/v16/v16-39.pdf It is the complete paper. Also there is a flash demo that shows an implementation. You know it is not just form generator. It is changing the software development rule. All I think is that we can create a very complex database from UI perspective. You can define all rules and logics from the UI perspective. For example, suppose you want to create a registration application. In registration form, you need to ask the city and province that applicant lives. With current methodologies, you will create a table, name it Provinces, another one, Cities and with a set of PK/FK relate them to each other. Now lets look at it from another point of view:

  You create a form (yes, diving directly to UI development), name it Provinces, put a TextBox and a submit button. Save the form. That is all you need, the application, the engine (what ever you like to call it) will produce an executable application that can be used to enter data in the form. Then enter CA, FL, ... in the generated form. Then create another form name it CitiesOfCA. Put a Textbox and whatever else you like in it. Enter Los Angles, San Diego, .... Repeat the steps for FL and ... . Now create the main registration form. Drag two combo boxes, tell one of them (I do like to think they are smart objects, you can talk to them!) to show you the provinces. And ask the other one to show you Cities. Something is ommitted There would be a form that you can simply tell Provinces form Item that for example by using CA, the related data must be shown from CitiesOfCA form. That is all! I know it seems some how complicated when you read these lines, but it is because you are thinking to current application development! I mean if at the day of programming inventions UIOAD was what they invented, now 3-tier application development was strange!

  Let me give you another example. I am from C++/DOS programmers generation. Those days, that we had to write everything, nobody could imagine that some day we can drag a DataGrid on a form and ask it to show us retrieved data from a database. It was because we could not imagine somebody else can create something like that!
  I will try to upload the Flash demo in next few days. Thanks for the time you spend on this issue.

  
  Regards

  
  
  

• WolfgangEngel

  I understand what you're driving at: layout at the UI, define some rules, and let the tools build it out with minimal knowledge of the underlying systems and principals.

  You really should look at the following links:

  http://en.wikipedia.org/wiki/Fourth-generation_programming_language

  and, more specifically:

  http://en.wikipedia.org/wiki/Fifth-generation_programming_language

  The point is that this can be done to a point, but it will be slow and get you about 90% of the way there. Others have spent a tremendous amount of money trying to solve the problems.

  Good luck!

  
  
  
• User Interface Oriented Application Development