- 901
- Cheshire, UK
- phillie11
- Bugs fixed.
- Power pack vehicles are being added in the next couple of days. Bear with us!
- Power pack vehicles are being added in the next couple of days. Bear with us!
) on some of my setups. But hey ho, might as well go for it now the cat is out the bag, happy Xmas(!), let me know.
Awesome - thank you
This is 'part 1' of how I was trying to find a solution to driver variable problem. I split this into 2, part 1 was about getting user to communicate feedback accurately, part 2 was taking that feedback and applying it to the setup. I used flow charts (I can't remember if there were 2 or 3 charts to be honest), which were very helpful to 'see' if any areas of the solution were being duplicated or it was becoming maladaptive and was going to end up chasing my tail. Unfortunately, this all got chucked a few years ago when I packed up my wheel etc.
All I got left are a couple of images used on my old sight (that might be applicable?) and a couple of testing videos I was going to 'use' to explain / show how I was testing. Attached are the images, these are just an example of communicating using visual cues rather than words, and these were for 'track limits' in our lobbies. If anyone knows how to post a vid I'll upload the testing vids, that's even if anyone is interested
Obviously, this was all 10 years or so ago, so can't remember everything exactly as it was, but hopefully this shows how looking at things from user perspective can be a bit different to creator perspective, maybe (?). I've tried to do this in a way which could (maybe) make it be easier to extract/copy onto a flowchart if need be. Also, any questions are effectively me 'thinking out loud' to myself i.e. it was basically a brainstorm with myself, which was interesting
I can't remember all the driver variables, but most of them were on the previous post, pretty sure if need be, any ones missed could be found. So, here's the 'brainstorm':
- Problem 1 - what happens when user asks for more than one driver variable - or when someone chooses a large group of different driver variables for the calc/app to incorporate onto base setup?
- Problem 2 - the sheer amount of custom values required to deal with all of this (I have no idea, but now it must be running into thousands), would that even be physically possible? Something like steering sensitivity would have multiple options just on it's own. What if two (or more) of the variables start to 'contradict themselves' in terms of what the calc/app is proposing for the 'answer'.
(NOTE: Part of this is applicable to PART 2 where there needs to be a 'decision' by the calc/app as to whether to keep on amending the original base setup, or to start afresh with a new base setup that is better suited to the users needs and therefore would need less amendments, which would reduce the chances of 'contradiction' occuring).
Possible solution:
The one 'thing' who knows the needs/requirements of driver/user better than anyone else is always going to be 'themselves'. So how about getting 'them' to do the fine tuning 'themselves'? But, that leads to a couple of potential new problems...
- Problem 3 - if user is using a tuning app/calc, chances are they probably don't 'know' about tuning generally (or maybe specific things like terminology i.e. understeer, springs, LSD). So, if there is a terminology issue, how can you get the user to 'fine tune' a setup, the calc/app has given them, to their needs?
- Problem 4 - also, if user has paid for the calc/app, they might not be too chuffed when calc/app asks them to 'do the fine tuning' themselves. I mean, this is what/why they're paying for the calc/app to do(?)
Possible solution:
Maybe if there was a way whereby the calc/app makes the user 'think' that it's the calc/app that's 'doing the fine tuning', when in fact it's the user who is doing it.
- Problem 5 - But, this would need a way for the user to accurately tell the calc/app what the problems are, which potentially takes us back to issues highlighted in problem 3(?)
Possible solution:
Before starting to address what is 'wrong' with the 'setup', maybe it would help if we could establish what is the best way for the user to accurately communicate the problem(s). Not everyone has the same knowledge of the terminology involved
Possible solution:
- Problem 6 - this feels like we're going back to what the original problem was (too many variables)
What about having an option on the calc/app whereby the user can choose how to 'communicate' the problem i.e. a bit like how a person 'personalises' what they see on screen when playing GT i.e. changing the view, what things to display. So, on the calc/app there will be some kind of an 'option'(?) for the user to select between, main possibilites/examples:
Using terminology (words)
Or
Using 'visual' cues i.e. images or video
- Problem 7 - language, what if user doesn't speak english(?)
Possible solution:
Maybe this reinforces the notion of using of visual cues, rather than words, (thus killing 2 birds with one stone?)
END PT 1
I looked upon these issues as driver variables are going to impact a setup much the same way as the settings within the setup i.e. understeer/oversteer, braking, mid corner, grip/acceleration. So the calc/app can 'react' in the same way whether the 'problem' was with the base setup or driver variable. So that is what part 2 was about.
----------------------------------------------------------------------------------------------------------------------------------------------------
Not sure how soon to post part 2 as this took a while, had to do this from scratch, from memory. Hopefully there might be something here that helps in some way, shape or form, or helps to give 'ideas' for the future(?)
Like I say, I don't know about your testing or history, I can only go by what I was experiencing. Maybe if you could explain how this is all tested on GT it could help? Where, how, who do you test with etc?
), and well, y'know, the rest as they say is history.
