[seanny]

What advice do you have for people who are wishing to create a user-friendly script?

My advice is to try and use dialogs where possible, they can take time to script but its well worth it in the long run.

[dusk]

About you advice, I dissagree. Dialogs can be a nasty thing when you need to do something quickly and you are in a vehicle for example....

My advice: lots of help messages. A user should NEVER need to think how to do something, unless that's the point of it.

[Basssiiie]

Several things to keep in mind:

• Your system (script) should be clear and easy to learn for someone with zero knowledge.
• Your system should speak the user's (player's) language, not the script language. For example, never use things like "insert vehicle ID". Use interfaces which are familiar to people.
• The amount of problems the user can run into should be minimal. Try to avoid "I don't know what to do"-responses as best as possible.
• If the user accidentally runs into a problem/certain situation, he must have the option to "revert the damages". This can simply be "close the window" after a window has been opened or an "are you sure?"-window when the user tries to delete certain information.
• Give the user feedback on what is happening. Simple errors like "Cannot buy this thing" are to vague, tell them the reason. In general, avoid vague messages.
• If the user still does run into problems, it's always the fault of your system and never the fault of the user. It means you failed to create a system that is self-explanatory. With the best system ever, an user should never have to ask for help.

These are just a few to name. There are a lot of things to take in consideration if you want to take it on professionally.

[Misiur]

Quote:

Originally Posted by Basssiiie If the user accidentally runs into a problem/certain situation, he must have the option to "revert the damages". This can simply be "close the window" after a window has been opened or an "are you sure?"-window when the user tries to delete certain information.

You can even go a step further, but of course this is way harder than creating simple confirmation box. If not for gmail undo, I don't know where I'd be today

[ColeMiner]

I've actually considered going one stage further than that, and never using "UPDATE" on user accounts at all (I considered this for the SQL port of y_users and may yet still implement it). Basically, whenever the user's data is saved, add a NEW row to the database with a timestamp, to be used along with the userid as an index. Then when they log in use "ORDER BY timestamp DESC LIMIT 1" (or whatever the exact SQL is) to only select the latest version of their account (indexes are used by both "WHERE" and "ORDER BY" clauses, so that would be the best way to do it).

This gives you (and the user if you so choose) a complete trackable account history. How this affects usability for them I don't know, the conversation kind of veered off slightly and I followed that. Sorry.

Don't worry about the number of rows created - if ******** can use SQL, your SA:MP server can do this!

[RajatPawar]

Quote:

Originally Posted by ColeMiner I've actually considered going one stage further than that, and never using "UPDATE" on user accounts at all (I considered this for the SQL port of y_users and may yet still implement it). Basically, whenever the user's data is saved, add a NEW row to the database with a timestamp, to be used along with the userid as an index. Then when they log in use "ORDER BY timestamp DESC LIMIT 1" (or whatever the exact SQL is) to only select the latest version of their account (indexes are used by both "WHERE" and "ORDER BY" clauses, so that would be the best way to do it). This gives you (and the user if you so choose) a complete trackable account history. How this affects usability for them I don't know, the conversation kind of veered off slightly and I followed that. Sorry. Don't worry about the number of rows created - if ******** can use SQL, your SA:MP server can do this!

OFF - TOPIC:

Isn't there another way - any queries sent by the script during an user session (not only for PAWN) are stored locally on a file, and the effects locally made. After the user ending his session would you finally execute the queries on the table and update the data. Not very efficient, but it provides you with an option to revert any bad commands that've happened. I can't remember what this method's named or about, do share if you know!

ON - TOPIC:

Dialogs are pretty much irritating when used for other things except registration systems - and somehow IMO, give the impression of the scripter being lazy. (not being creative enough to create stuff)

[Misiur]

Can someone point me to SQLite performance tests? My domain is MySQL/PostgreSQL, and the threading is really big advantage for me when choosing between mysql or native sqlite. ******** had problem with php so they created hiphop, so I don't really believe MySQL (MariaDB DBMS now) is the best choice.

[ColeMiner]

HipHop IS PHP, and even if it wasn't that has nothing to do with MySQL so I don't see how you can draw that conclusion.