Say for example I am getting a range of integers from a user:
Generate between nnn and nnn widgets.
Yes, most users will ensure that the first number is equal to or less than the second number:
Generate between 3 and 7 widgets.
But then there's that user, who wants to enter this data "back to front";
Generate between 7 and 3 widgets.
Do you quietly switch the fields around when the user clicks OK/Apply so, in the example above, you change the range of 7 to 3 back to 3 to 7 in the GUI? This might not be so practical on a web form where the user enters some data and then submits the form never to see it again but I'm thinking more in terms of a desktop application's settings page where the user's input is saved and subsequently viewed and edited again by the user.
Is it more important to try and educate users to enter a range that "makes sense" via error/alert messages, or quietly cajole their entries into the shape an application is expecting?
I suspect the "cajoling option" is more preferable, but could this "hey the program messed with my data!" approach be a problem for users?
I am currently writing an application that has a handful of these user-configurable ranges so I'm very interested to follow the general consensus of the SO experts.
If the user enters data incorrectly you shouldn't assume a particular pattern of error and automatically correct it. Either report the error to the user and ask them to correct it or suggest a correction that they can approve. In your example, what if the user intended to type 7 and 13 but simply mistyped. If you changed it to 3 and 7 you've entered incorrect data without the user's knowledge. I'd probably do the simple thing and use a visual alert when incorrect data is entered (but before it's actually submitted) and refuse to accept incorrect data, returning an error if it is submitted incorrectly.
Related
I'm using Watson Assistant Chatbot..I want to save a variable from the user input by enabling Slots and system entities like #sys-number.. I can save number by choosing check for #sys-number, or saving date by choosing check for #sys-date... But for text/characters I can't find something like #sys-text or #sys-char..
I tried to save text while check for #sys-number, but the answer is not saved into the variable and the question keep repeating in th chatbot console.
So, how can I use Slots to save text from user input, I mean what should I put in "check for", please?
Thanks,
Numbers are always numbers, no matter your language and context. Dates are always dates as well.
However, "texts" can mean many different things, and they depend on context. That's why you need to create a separate entity for each meaning in your context.
For IBM Watson Assistant, there is no reason to detect "any text" unless that text means something in your context.
Supposing you want to detect the word "smartphone". For Assistant, there is no reason to detect this word if it doesn't relate to any entity.
So, you need to create an entity (e.g. "#Product") and then give it a value named "smartphone". Then, whenever a user types "smartphone" in your Chatbot, Assistant will be able to recognize "#Product:smartphone".
In your Slots, in the "Check for" field, you can put "#Product". It means that if Chatbot doesn't detect any #Product (e.g. "smartphone"), it should repeat the question until it finds a valid product.
All over the internet I see examples/tutorials in which they create cloud variables. But when I create a variable (I've used scratch 2 and 3) I get
But I would like to get is this:
I just watch a youtube tutorial in which was told that for cloud to work you have to be a scratcher for at least 3 month (I have an account for 4 months now). So what do I have to do to get the cloud checkbox?
There are two levels (for normal users) of scratchers: a New Scratcher, and a Scratcher.
When you create an account, you get the status of a New Scratcher. This is what your status is now:
Then, to become a Scratcher, there are certain secret criteria you have to meet. It's some sort of combination of having like three projects shared, having commented five times, and following a few users, if I recall correctly. Then you'll get the Scratcher status, and it'll look like this (using me as an example):
Basically - you have to participate more on the site to lose the status of New Scratcher. Here are the requirements for becoming a full-on Scratcher.
Once you meet those criteria, head to the "data" section of blocks, press "create a new variable", and then tick the "cloud variable" checkbox. Note that unlike regular variables, cloud variables can only contain numbers up to 256 characters long per variable with a maximum of ten variables per project ID (trailing and leading zeroes are allowed), not letters or non-numeric characters apart from 0123456789.eE-+.
You have to become a "Scratcher", not a "New Scratcher".
You just have to sign in.It was a mistake that I also realised when I started working with cloud variables. Even if you have an account and it still does that, just verify your email, it will work.
So I've started learning access due to necessity, as the person who was in charge of it passed way and someone had to keep it going.
I noticed a very bad (at least IMO) behavior in all databases he created: Every single form was bound directly to a table or saved query. This way, if the user opened a form, he had to complete all the steps he was supposed to do, because if he closed the form mid process (or the computer froze, or anything of the sort), the actual data would be compromised as it would be half complete. This often times broke everything in the process chain, rendering sub-sequential steps impossible to be performed and forced me to correct data manually directly in the tables.
As I've start upgrading his stuff and developing my own, I've been trying to learn ways to allow the data to be edited in the form only, making it possible to cancel the process anytime or save the changes all at once in the end.
If the editions were simple, I discovered that I could create a recordset, copy relevant data to unbound fields in the form and, in the end, if the user chose to, copy the data from the form fields back to the recordset.
Other times more complex solutions were required, as I would need to edit several pieces of data at once in continuous forms, "save" them, run more code, maybe add fields to hold the information originated from that processing and so on. I then learned about using temporary tables, but did not like it, since it tended to bloat the db. I even went on to creating temporary databases during code execution that would host the temporary tables and be destroyed in the end, but that added too much unnecessary complexity.
Nowadays I'm using disconnected ADO recordsets to hold the temporary data and fields. It works but has its limitations.
So I'm wondering, what is the best way you - much more experienced than me - guys use to approach this kind of scenario? Is using in memory ADO recordsets really the best way around?
I think you are mixing two things that a form does that have completely different requirements. Editing existing records (and bound forms are great for that) and creating new records (where using a straight bound form can result in creating incomplete records). The way to approach it depends on many things but mainly to how much data is necessary for a new record to be considered "complete".
I usually do one of the following things:
Create an unbound popup modal form for adding new records where only the necessary fields are present. Once complete it loads the new record to the main form for further editing.
Use the above method except the form is not a popup one but a set of unbound fields in the footer or header of the main form.
Let the user create new records but bind validation on the OnClose (and/or other appropriate to your situation) event of the form that deletes the half-filled record if it does not validate.
Let users create new records in the bound form but have a 'cleanup' routine called either on a schedule or based on user actions.
Ultimately if your business process requires the majority of fields to be manually added/edited every time a new record is added or edited, you are better off using an unbound form.
This way, if the user opened a form, he had to complete all the steps
he was supposed to do, because if he closed the form mid process (or
the computer froze, or anything of the sort), the actual data would be
compromised as it would be half complete
No, if the computer freezes, then no data is saved to the table. This is the same if you used a disconnected reocrdset and a un-bound form.
If you use the before update event in the form that has some verification code and does a simple cancel = true, then the forms data is not saved nor is the table updated. Again, if you used a dis-connected record set and the user closes the form, you have to test the data – and again you can either choose to write out the data or not – this effect is ZERO difference from using a bound form to a table or a disconnected form.
If the editions were simple, I discovered that I could create a
recordset, copy relevant data to unbound fields in the form and, in
the end, if the user chose to, copy the data from the form fields back
to the recordset.
No you don’t need to do the above. The above achieves nothing and only racks up additional development hours and increases cost of the application. In near all cases in-bound forms increase development costs over that of a simple form bound to a table. So the original developer had the correct idea. You can control the update of the underlying table in near all cases to achieve the required verification. Forms only save and write the data out if the developer allows as such.
So Access forms when bound no more or less write incomplete data out to a table if you place verification code in the forms before update event. A half-filled bound form, or a half filled un-bound form with dis-connected reocrdset BOTH will not write their data if the computer freezes.
And BOTH types of forms will not write out data to table until such time your verification code has completed.
Access is not designed for un-bound forms, and tools like vb.net, or even VB6 had a whole bunch of cool wizards and support for un-bound forms. In access, we don't have those wizards. And when you use UN-bound forms then you loose tons of form events. You in effect get the worst of both worlds, since you lose use of form events and have no wizards or support for un-bound. Even just the several delete record events we have are rather amazing.
You lose use of me.dirty, on-insert, me.newReocrd, forms after update events - the list of features you toss out and lose is huge. And if you want a button to write data to the table (such as a save button on the form), then just go:
If me.Dirty = True then
me.Dirty = False ' this forces your verification code to run
End if
There are FEW use cases in which in-bound forms will benefit you, but they will cost you rather much in terms of development times.
I'm looking to bulk input data from google forms. This involves 2 sections:
Initial Conditions
Observations
Everyone who wants to input data will be inputting 1 set of initial conditions, followed by somewhere between 5 and 20 (maybe more?) observations of multiple variables:
Name
Date
Color
Quantity
Type
The problem is that I don't want to have to make people re-enter the initial conditions each time they submit a form.
Ideally they would be able to select a response after adding one observation:
Add another observation
Conclude session
The thing I don't know how to do: Add another observation would open a new blank observations page.
Anyone have any ideas about how to make the appropriate form?
I keep seeing questions floating through that make reference to a column in a database table named something like DateLastUpdated. I don't get it.
The only companion field I've ever seen is LastUpdateUserId or such. There's never an indicator about why the update took place; or even what the update was.
On top of that, this field is sometimes written from within a trigger, where even less context is available.
It certainly doesn't even come close to being an audit trail; so that can't be the justification. And if there is and audit trail somewhere in a log or whatever, this field would be redundant.
What am I missing? Why is this pattern so popular?
Such a field can be used to detect whether there are conflicting edits made by different processes. When you retrieve a record from the database, you get the previous DateLastUpdated field. After making changes to other fields, you submit the record back to the database layer. The database layer checks that the DateLastUpdated you submit matches the one still in the database. If it matches, then the update is performed (and DateLastUpdated is updated to the current time). However, if it does not match, then some other process has changed the record in the meantime and the current update can be aborted.
It depends on the exact circumstance, but a timestamp like that can be very useful for autogenerated data - you can figure out if something needs to be recalculated if a depedency has changed later on (this is how build systems calculate which files need to be recompiled).
Also, many websites will have data marking "Last changed" on a page, particularly news sites that may edit content. The exact reason isn't necessary (and there likely exist backups in case an audit trail is really necessary), but this data needs to be visible to the end user.
These sorts of things are typically used for business applications where user action is required to initiate the update. Typically, there will be some kind of business app (eg a CRM desktop application) and for most updates there tends to be only one way of making the update.
If you're looking at address data, that was done through the "Maintain Address" screen, etc.
Such database auditing is there to augment business-level auditing, not to replace it. Call centres will sometimes (or always in the case of financial services providers in Australia, as one example) record phone calls. That's part of the audit trail too but doesn't tend to be part of the IT solution as far as the desktop application (and related infrastructure) goes, although that is by no means a hard and fast rule.
Call centre staff will also typically have some sort of "Notes" or "Log" functionality where they can type freeform text as to why the customer called and what action was taken so the next operator can pick up where they left off when the customer rings back.
Triggers will often be used to record exactly what was changed (eg writing the old record to an audit table). The purpose of all this is that with all the information (the notes, recorded call, database audit trail and logs) the previous state of the data can be reconstructed as can the resulting action. This may be to find/resolve bugs in the system or simply as a conflict resolution process with the customer.
It is certainly popular - rails for example has a shorthand for it, as well as a creation timestamp (:timestamps).
At the application level it's very useful, as the same pattern is very common in views - look at the questions here for example (answered 56 secs ago, etc).
It can also be used retrospectively in reporting to generate stats (e.g. what is the growth curve of the number of records in the DB).
there are a couple of scenarios
Let's say you have an address table for your customers
you have your CRM app, the customer calls that his address has changed a month ago, with the LastUpdate column you can see that this row for this customer hasn't been touched in 4 months
usually you use triggers to populate a history table so that you can see all the other history, if you see that the creationdate and updated date are the same there is no point hitting the history table since you won't find anything
you calculate indexes (stock market), you can easily see that it was recalculated just by looking at this column
there are 2 DB servers, by comparing the date column you can find out if all the changes have been replicated or not etc etc ect
This is also very useful if you have to send feeds out to clients that are delta feeds, that is only the records that have been changed or inserted since the data of the last feed are sent.