Friday, October 24, 2014

User resistance

There was a nice confluence of reality and theory the other day. During the week, I had read a few papers on 'user resistance' which I want to include in my literature survey. UR is inversely related to 'perceived usefulness', which, as the literature puts it, is "a surrogate for system success". In other words, if a user perceives a function to be useful, then the user will use this function and system success will be enhanced; if the user perceives that the function is not useful (or by adding overhead, even detrimental), then the user's resistance will grow and system success will not be enhanced.

In the real world, someone wanted that some metadata regarding customers (the customer's business sector) become compulsory; when a new customer card is opened, the operation can not be completed without defining a business sector. As this field has not been compulsory until now (and in fact, there had been very few values defined), no one had ever bothered filling it in. Entering a value into this field - especially when the customer is being defined and the information not necessarily at hand - is going to be perceived as irrelevant overhead. Overhead = no perceived usefulness = increased user resistance.

The person who wants this field to be compulsory is going to have to write a letter to all the users who define customers, explaining what the informational value of this field will be (how it will be used in the future) and why it is important that 'real' values be entered (because one defense mechanism which people have developed in order to handle compulsory fields is to enter any value - but necessarily the correct one). Hopefully, we will be able to raise the level of perceived usefulness and thus improve system success.

With regard to the literature survey: the completed document is 93 pages long and contains about 41K words. It turns out that the entire thesis is limited to 80K words, so some serious editing will need to be done on the survey. I know that I included far too many direct quotes from papers, so it should not be too difficult to elide the extraneous material. My supervisor is on the job.

Note new values for Stack Exchange and Musical Practice and Performance below!
[SE: 3628; 2, 15, 35
MPP: 574; 0, 1, 6]

Monday, October 20, 2014

The seach for serendipity

During the final days of working on the first draft of my DBA literature review (that is, last Friday), I found two papers which initially seemed interesting but of doubtful relevance. One [1], a scholarly paper on the subject of serendipity, was downloaded just for the fun of reading the paper. The authors describe serendipity as "making discoveries by accident and sagacity of things which one is not on quest of” [is there not a redundant 'of' in that definition?]. This subject has absolutely nothing to do with my research, but it's interesting, as I've noticed that frequently good ideas seem to come from random events.

The second paper is entitled "Cognitive style factors affecting database query performance" [2], and of course was intended for the section on cognitive style. The paper discusses how cognitive style affects the accuracy of SQL statements; an example appears on page 260
SELECT ITEMB.ITEMNO, RECEIPTSB.RECREPNO
FROM ITEMSB, RECEIPTSB
WHERE ITEMSB.ITEMNO = RECEIPTSB.ITEMNO
AND RECEIPTSB.PAYDATE < (RECEIPTSB.RECDATE + (0.5 * RECEIPTSB.TERMDAYS));
This isn't quite the syntax which the authors use as they neglected to use table identifiers for certain fields. As written, one can see that this statement uses implicit joins (otherwise known as SQL-89 syntax) as opposed to the clearer explicit join (aka SQL-92 syntax); see here for further discussion of this topic. Looking at it now, there is no need whatsoever to include the ITEMSB table in the query. But I digress.

At first, I thought that I would write a few lines about the paper, stating that Priority hides SQL from the end users ("I wouldn't know an SQL statement even if it bit me in the finger") thus awarding the paper a very low significance, but it suddenly struck me that if I ignore the SQL part and show how the research described in the paper examines how people solve database problems at work ("show all the clients who didn't purchase anything in 2014"), then the paper has high relevance. I wrote about this before, when someone needed data about products which could only be retrieved by accessing three different screens. The cognitive style will play an important part in how the data is retrieved and how accurate it is. Of course, I wrote a program/developed a report (using SQL) to do the work, so that users will be able to access accurate data whatever their cognitive style. In the end, I wrote nearly two pages about this paper which suddenly became extremely relevant.

I see that my writing style has been strongly influenced by the literature review; I even include references.



[1] Foster A.E. and Ellis D., (2014), "Serendipity and its study", Journal of Documentation, Vol. 70(6), 1015 - 1038
[2] Bowen, P. L., Ferguson, C. B., Lehmann, T. H. and Rohde, F. H. (2003): "Cognitive style factors affecting database query performance", International Journal of Accounting Information Systems, 4(4), 251-273.