TLDR; Every approach to automating has risks, issues and benefits. Often we don’t think these through. When we do we will see that automating has a different set of answers than automating strategically. This helps reinforce the difference, without having to stick to definitions.
In my conference talks and on my blog I make a distinction between Automating Tactically and Strategically. In this blog post I will conduct an exercise to look at the benefits, risks and issues associated with a particular example of automating tactically.
I previously presented an example of automating tactically in the blog post and sample code or unchecking all the Twitter Interests in a blog post.
In this blog post I want to perform an exercise of assessing the risks, issues and benefits of this approach for this specific Twitter example.
This is something I encourage people to do, regardless of the tactical or strategic nature of your automating, because it helps reinforce the distinction between the two concepts. You will identify different risks, issues or benefits depending on the tactical or strategic nature.
Exercise
Since this post became quite long in the writing. I encourage you to do this exercise for yourself first.
Considering the approach taken in the blog post
- What Risks, Issues, Benefits can you identify?
- What points; positive, negative, neutral can you identify?
And I’m asking you to do that first, so that my write up below doesn’t limit or bias your thinking.
Some Notes on Automating
- Not all automating is for testing.
- Not all automation is Test Automation.
I’ll go further and say.
- Most automating is not for testing.
- Most automation is not Test Automation.
There are tactical benefits for this type of approach to be used in Testing, but I’ll leave that to another blog post. e.g.
- replicate long data set painful to test situations
- test for ’timing’ issues from the user
- soak test functionality
I think it is very important to make a clear distinction in between:
- “Automating”,
- “Testing” and
- “Automating to support the Testing process”.
The latter is a small intersection of two larger sets.
Tactical Benefits
The benefits for this automating, that I will consider in this post, are for the user, not for testing.
- managing twitter interests clearly has to be done regularly
- managing twitter interests (based on tweets I’ve seen), is a painful and time consuming process
- learn more JavaScript
- deeper technical understanding
- take control of your user experience
Pain, Time
Common justifications for automating include: things we do regularly, stuff which is painful to do, time consuming activities. Automating this save us time.
We are unlikely to manage preferences regularly when the process to do so is painful. Having an ability to automate, might cause us to manage the process more regularly.
Knowledge
In order to understand the script, learning some JavaScript is useful. This is particularly important when copy and pasting stuff off the Internet into your browser when you have a logged in session. If you don’t understand what the script is doing, then please don’t run it.
You ultimately are responsible for what you type in. Make sure you understand the scripts that you are using. This unfortunately applies to all systems and plugins and tools.
Many tools and services, we can’t ‘see inside’ or they are too large to Grok in one viewing. Tactical small scripts like this have the benefit that they can be understood if taken piece by piece and web searches are used to gather information. And they can be deconstructed to run small segments until we understand what it does.
I also recommend reviewing your Twitter “Apps and Sessions” regularly.
https://twitter.com/settings/applications
I review a lot of tools and services, many of which use a Twitter login, but when I look in “Apps and Sessions” I can see that they are still there, and they have write permissions for my Twitter feed. I try to review the “Apps and Sessions” regularly to make sure that I have only included reputable services that I actually use. And that they have permissions that are appropriate for the actions I use them for.
Sometimes I login to a tool using Twitter, then after finishing, remove the tool from Apps and Sessions. When I need to use the tool again, I will grant it the permissions it needs. This is particularly true when the tool has write access.
So the benefit here isn’t just knowledge of JavaScript. It is an increased awareness of security considerations and safety with online systems.
Take control of your user experience
When the timeout values are tweaked to the optimum effectiveness for the user at the time they use the script this script seems to work well.
It increases my user experience with Twitter.
A deeper range of options about how we interact with applications opens up more options for us to take control of our user experience.
e.g.
- Instagram posting functionality from desktop
- Workarounds after reading ‘hidden’ error messages
- Creating new functionality
Instagram posting functionality is only accessible from mobile devices, unless you know how to take control of your user experience on the web. I frequently post to Instagram from my desktop.
Error messages are often hidden when using online systems. I’ve found hidden error messages in network traffic and in the Console, for: banking, online purchases, posting to sites, etc. The error message has allowed me to take action that would have prevented someone else, who did not have this level of control, from completing the action.
Adding additional functionality that does not exist. e.g. something as simple as a ‘select all’ or ‘unselect all’ can make a massive difference to the usability on a web site.
e.g. I once won many of the ‘freebie’ giveaways in an online conference because to enter the prize draws you had to select (individually) the entries from a list containing hundreds of items. Most people didn’t read the list or select more than a few of the early ones. I automatically selected them all.
I’ve also added ’links’ to pages, so that I can lookup definitions on other sites.
There is so much scope for enhancing our experience of Web Sites and applications, when we learn simple techniques for augmenting them.
Tactical Risks
- User might not have the technical experience to use the script
- Twitter might not be expecting people to uncheck everything
- Unchecking everything might change the user’s experience of Twitter
- Automating this way might be against the terms and conditions of Twitter
- Twitter might change their GUI making this script non-functional
What risks can you identify?
User might not have the technical experience to use the script
Automating Tactically is generally more specific than Automating Strategically.
It is a tactic, designed to be used by a small subset of people. Often only the person who created it. The wider the user base, and the easier it needs to be to use - the more strategic it becomes.
This is one of the attributes of Tactical Automating.
I addressed this risk slightly by changing the timing on the script, releasing it on Gist to make it easier to copy and paste, adding some simple instructions in the Gist and on the previous blog post. I did not fully address this because the time it would take would offset the tactical advantage. The aim was not to make a generic script that everyone could use. The aim was to solve a problem I experienced and share it for those people who have the experience to use it.
Twitter might not be expecting people to uncheck everything
Sometimes companies create functionality, and then retrospectively realise that, due to government regulations, GDPR, etc. that they need to allow the user control over the data.
The functionality introduced for user management is not often designed with the user or the use case in mind.
These are often rich sources of extrapolated issues i.e. the functionality itself is not buggy, but if many people use it, or the number of data items used by the functionality increase the processing time or payload size might be extrapolated into an issue.
That seems to be the case here. I encourage you to use dev tools or a proxy to view the messages and responses that this functionality generates. Clearly the technical infrastructure and implementation behind this was not designed for efficiency of data usage, or feedback to the user in terms of control of their data.
Unchecking everything might change the user’s experience of Twitter
Just because you can uncheck everything, doesn’t mean you should.
What does this data control? Is it ads, promoted tweets, people you might like to follow?
I can imagine that it might change the ‘home’ view where some posts show and some don’t. I have no evidence for this, but I assume the interests have to be used for more than ads.
I mitigate the impact of this by never using the ‘home’ view, I have to switch back to latest every few days. And I use clients that always show tweets in most recent order. Other people might not do this, so their usage of Twitter might be impacted.
The only information I could find on Twitter Interests was for ad targetting:
https://business.twitter.com/en/targeting/interest.html
So presumably if you unselect everything. Twitter has to show you untargetted ads, or use targetting that is not configurable by the user.
I mitigate this risk by using Twitter clients that connect to the official API, since the official API does not serve ads to the client. So I don’t see any ads when I read Twitter through these clients. Other people using this script might not have additional systems in place, so leaving some of the Interests selected might actually be beneficial for them.
NOTE: when I used the Android application to access Twitter this afternoon, I saw a notice saying that “Personalised Ads” have been switched off. I think this is an impact of switching off all interests. I didn’t re-enable this.
Automating this way might be against the terms and conditions of Twitter
Systems have Terms of Service. Automating systems in unofficial ways can be viewed as against terms of service.
After reading the Terms of Service I don’t think it is, but also consider that this approach does not use any unofficial APIs or secret functionality.
It uses the GUI provided by Twitter for managing the Interests, and issues ‘click’ events on the checkboxes, as a user would do. Originally it did this faster than a user would do, but that was because I assumed that the API Twitter was using was designed for the XHTTP interface that they were using and would only transmit immediate changes e.g. {"interest":"Shoe Trends", "status":false}, but it doesn’t.
TOS are a tricky business, and usually open to interpretation by the companies involved, so some actions can be interpreted as against the Terms of Service.
When working on your own systems this usually isn’t an issue. And if you find a way to use the system using its provided interfaces in such a way that it causes server issues then it is usually indicative of a flaw in the system design.
I remember a self inflicted DDOS issue that we experienced at a company I worked at in the past. We had gathered all the HTTP requests used by the GUI, included them in our performance and stress testing profiles, and the system worked fine. When we went live, the system fell down. The cause was a JavaScript call used for homegrown tracking that was not present in the performance and stress HTTP profile because it was added to the system after this testing, and we were not aware it had been added.
Twitter might change their GUI making this script non-functional
Automating Tactically often means:
- using unsupported APIs discovered through HTTP analysis,
- sending HTTP messages that the GUI generates but bypassing the GUI generation
These might change, causing your tactical automating to fail.
In which case, you fix it when you next run it.
Strategic automating relies on official or versioned APIs, and change communication to keep the automating working in step with the system.
Tactical Issues
- 500 errors
500 errors
In this approach the issues I found were:
- when run, 500 errors can be seen in the console.
Different people experience different numbers of errors. I received very few, and it made little to no difference on the outcome of running the script. Other people received more, and it made a difference to the outcome.
From the point of view of the user of the tactical automation, this is an issue. And they might not understand the script well enough to change the code to increase the waiting time, to allow the script to complete.
Note that I experienced 500 errors when manually interacting with the system. e.g. I ran the script. Saw some 500 errors in the console. Stopped the script. Tried using the GUI manually, and encountered 500 errors. I suspect that after a certain number of requests, the backend is still processing the requests resulting in new requests experiencing 500 errors. These are only visible to the user in the console. Not on the screen. If I was working on a mobile device, I wouldn’t see any errors and would assume that the changes I was making were being accepted, even when they were not. This might explain why people were reporting on Twitter that they made changes to their interests but ‘Twitter added them all back’ the next day. I suspect these people were not automating, but experienced a potentially related issue.
e.g. a search for “twitter interests rechecked” “twitter interests back”
The issue for Twitter is that if it is a system issue, then people don’t know that, and are blaming Twitter for: interfering with their feed, lacking integrity, conspiracy.
