Notes on User Interfaces based on Artificial Intelligence

The grid provides or at least at the moment promises a desing and user interface web technology that changes based on the average user pattern of a site. The usage is measured analysed by different artificial and data-mining algorithm and a new design a new, a new site structure is proposed automatically. 

As the idea seems pretty much science fictional for the first run but actually the idea itself is not so wild. Basically every search based user interface and application follows the same pattern. Certainly not only whole user interface is restructured, only a part and it is basically regarded to content as opposed to structure. As an example consider an news portal that automatically shows some information based on different sources and selection criteria. Despite the field is rather regarded as search than like data mining, the pattern is pretty much the same: 

 1. collect data

 2. analyse data

 3. show something different on the user interface.   

The two differences are : 

 a. The field is regarded as search and not data mining or artificial intelligence: well it does not seem to a be a huge difference. Basically most of the search and indexing algorithm show some similarity with data-mining. Actually the two fields were pretty much common a couple of years ago. 

 b. In search based applications, only small area of the user interface can be dynamically changed, like a search result or a filter result. However it is not necessarily a big different either, technically the whole user interface could be reconstructed. If it makes sense from an endure point of view is certainly a more difficult question.   

Notes on self adaptive SharePoint Environment

Recent trends in Data-Mining software solutions are going in the direction that data-mining and intelligent analysis solutions are getting cheaper and cheaper. It actually does not only mean the price of the software, but the ways of integration the different solutions are getting easier and easier as well. This provides new possibilities in the classical software and application development as well.

Having the possibility of collecting data about a running application, like application usage, logs, infrastructure data, and having the possibility to analyse them with data-mining tools, provide eventuelly the way of proposing a application improvmenet. Based on data measured and cheap data-mining possibilities a general SharePoint application development process can be defined as follows:

0. Analyse: This one is a classical requirement engineering step, analysing the requrements to set up an initial application. However, the requirements should not only be collected by interviewing the stackeholders, there is a possibility to analyse existing documentations or data, that might also be supported by data-mining. 

1. Setup: This is the classical step for setting up the system, planning and installing infrastructure components, developing and delivering custom solutions.

2. Collect data and usage: SharePoint collects pretty many data out of the box, like standard log files, search or usage and health data. As most of these pretty much infrastructure oriented it is important to measure data about certain application usage as well.

3. Analyse: The collected data has to be by different data-mining tools analysed.

4. Propose new structure: based on the data and analysis new application structure can be proposed. The improvement might be only infrastructure oriented to achieve a better performance, however completely modified use cases or business processes can be defined as well.

Repeat from step 1: The process can be actually repeated from the beginning, the new structure or can be again set up and the application usage can be again measured and analysed.

A social method for software development

If you consider software development there are basicaly different models of doing it like, 

the types of classical waterfall, V or W models and of course the different agile methodologies, ranging from extreme programming to SCRUM. 

All of these methodologies suppose however that there are some kind of a more or less explicite spefication what should be develped. 

Considering the waterfall model the specifications should be explicitely given as a set of requirements to start the development itself. 

Having developed the reqirements there might be one more round to extend both the specification and the covered the changed requirements. 

Agile development focuses much more on the changing of the specification, having more iterations and more check and validation of the requirements. 

Agile development usualy does not suppose very strongly that the reqirements covered in the form of a precisely described specification, 

but it is supposed that there is at least someone like a product owner who has got an explicetly view what should be developed. We can say that with agile methodologies, 

even if it is not written the product owner knows exactly the specification. 

What happens however if collection the specification in an organisation is problematic, 

if noone is able to act as an efficient product owner because getting information from the members of the company would require too much time and effort. 

Not to speak about writing a precise specification that would be much more complicated. 

Is there a way in such a situation to carry out an efficient software development ? 

Is there a way to have a software development methodology that actually supports collecting pieces of the specification itself ?

I think the answer is yes. 

Let we imaging that we do not want to have a development in which everything has to be developed from scratch instead we are dealing with components that are not necessarily ready but they are at least in a prototype that can be somehow demonstrated. 

Let we imagine that we have (C1, C2, C3, ... CN) prototype or demonstrable components in our system and we provide user interface called metamodel in which the users or customers can configure demo applications and like them or dislike them based on different like mesaures. 

Like supposing one customer wants to have only the (C1, C3) components in a certain configurations another customer wants to have only (C2) components and the third one only (C2 and C4). 

The system that should we realised is the combination of (CN...CM) components that are liked the most and makes sense to build it up. Certainly they are fuzzy concepts, how the components can be congigured and how the system can be build are depending on the exact domain and technology.

In this way creating the specification is more like a social network: people like on software components and configurations instead of posts or pictures (see the following picture). 

Having this model we should not sctrictly follow the classical principle : developing one software at the end of the process. 

Several other outcomes can be imagined as well :

- One software at the end (one size fits for all): based on the likes and techniqual restrictions we still choose one model to implement. 

- Several variations: we choose some of the most liked solutions and implement as several variations, from which the userers might choose one on their own. 

- Self service software creation (mass customisastion): if the components are not just prototype but practicaly 100 percent ready solutions, there might be a possibility to provide everything and the users can configure everything on their own.

Let have an example, realised in SharePoint.    

We want to develop personal records in a company for storing and showing information for each person. We are however not very much sure exactly which information should be stored. 

Let we say, first name and last names are for sure but othwervise noone knows which metainformation should be used. 

Let we have the following simple meta factory with the following metainformations: 

- ObjectName - name of the object that we want to store, in our example there is only one object called PersonalRecord.

- PropertyName - the name of a property of an object.

- PropertyType - the type of a property of an object.

- ProeprtyLike - information who wants to realise which property, for example in our example there is only one property that wants to be seen only by "test" user, there are only two properties that wanted to be implemented by "test2" user : "FirstName" and "LastName" and so on.

In this sense the components are practicaly the objects and property elements (see the following picture).

Pressing a preview button each customer can see how the choosen configuration could look like, in this sense they do not just choose blindly, but there is a certain view, a certain idea how the choice might look like. As an example having the administrator choice, the given configuration might look like as follows. 

It is important to note that the preview should not necessarily be the final version; it can be regarded as a sketch as well. Like in our example the concrete design is pretty poor, however in a final implementation it can be much more fancy.

​

Based on the likes and users' preference there should be a review and a decision, like: 

- implementing some of properties, mostly that are liked by the most and create one common profile

- implementing more property sets, so the users can choose which one they want to apply

- or simply implementing everything