Google Tag Manager has been an amazing addition to the typical data analysts set of tools. The problem is that with multiple people, agencies and generations of internal users, it can turn into a “Franken-Stack” of technologies without having a central set of control.
Problems caused by Tag Manager gone wild
For those of you who don’t do the biannual tag manager audit, you could be experiencing one of these things:
Slow Performance — Too many tags can slow down the performance of your site. Just because they are firing later, doesn’t mean that they aren’t using up users’ bandwidth
Don’t touch it, it might be important — Especially if the team isn’t aware of the purpose of all the tags, it is very easy to leave a tag in place just incase its driving a marketing activity that is making money.
Loss of Control — This is the most tough to see, where by the team feels like they no longer control their stack and it becomes a black box of magic tricks. The team should be driving whats in the tag manager container — not the other way around.
The Tag Manager Audit Template
The tag manager audit template can be found here and is free to use and modify.
It covers key things such as :
Building a common terminology to refer to tags
Identifying the purpose of the tag. No purpose == bin
Making sure there is a contact for the tag to get updates, get improved documentation or just to get status
Links to implementation details. All your tags should be treated as software releases and have details of what they do, what the code should look like and most importantly how they are tested.
What pages they should be found on. Thisis key to identify if there are pages which are focus for performance improvements, then its quick to identify if there are any tags that can be modified to deliver the business goals.
To make sure you have a fighting chance to succeed as a team — you need to make sure that all your tools are operating on point. Tag Manager is one of those tools which can be a great asset or a great hinderance. Now is the right time to get Tag manager on your side
Being a developer, an analytics geek and someone who has managed app teams for several years I have seen the different sides of what goes into app delivery and its from this unique perspective that I would like to share some insights I have picked up to help improve how apps are made in your projects.
Conflict in Projects?
In many cases I am amazed by the amount of conflict that is caused through not taking a “one team” approach to building apps and websites. I have been part of projects where conflict and problems have been virtually encouraged through enforced separation of the design and the development function. ( going against my advice) There really is a better way — and I hope this post helps others to avoid the same pitfall.
Why is UI design and UX important ?
One of the most important aspects that distinguishes iPhone and iPad apps are their dedication to being beautiful, dynamic and usable.
The Apple Human Guidelines is an excellent resource which helps those building apps to understand the nuances of design and user experience. The introduction for the animation section says this best:
Beautiful, subtle animation throughout iOS builds a visual sense of connection between people and content onscreen. When used appropriately, animation can convey status, provide feedback, enhance the sense of direct manipulation, and help users visualize the results of their actions.
In IOS development, building UIs are the closest that you come to talking to your end users. A great UI is like a great conversation that flows and brings those that participate in it a lot of happiness and joy.
By contrast, an inconsistent, misaligned conversation is one that makes users feel uncomfortable and they will seek out to find other great conversations in the room and leave your app lonely in the corner.
Ok enough labouring this point…I hear you say… UI needs to be great. Lets crack on.
The design process gets off to a good start
Designers spend ages agonising over ideas and discussing with customers over the smallest details of the app or site they are creating.
They have often iterated through multiple versions, and done multiple rounds of feedback to get it just right.
It gets signed off and validated right up the business chain. Without involving those that are actually building the product, there is a big risk. This is the point that things start going off the rails 🚨😱
At this point, its presented to the developer team( usually with a filename such as Design Final final .pdf)
Starting developers with a locked design ( Don’t do this!)
This “wonderful, perfect design” has becomes set in stone, and any changes that the developers suggest afterwards are tantamount to destroying this wonderful UI and all the work thats got in before.
Even worse, the poor designers, who have birthed this design are almost forced to become guardians of what works for the audience. They feel obligated to defend it, justify it, and protect it from the evil marauding developers.
A better way: Involve the development team earlier
The real key to success would have been involving the developers a lot earlier in the process.( ideally step 1 above).
The developers’ role during the design phases should be to:
suggest ideas to streamline the development. In one case I suggested that creating a radio button in the top right hand corner would allow users to more easily access a feature. The designer didn’t know it was possible- and we removed 2 screens from the entire app flow — and end users loved using it. £1000’s of pounds in development costs saved in 5 seconds.
validate the design as being feasible. I once had a project where we had to do colour detection to unlock levels of a game. The problem is that colours can look significantly different depending on what the light is. This was flagged early so the designers and product owners came up with another approach based on developer teams suggestions.
3. suggest new features. Based off the latest IOS apis there are a goldmine of new exciting features to be tried.
4. technicallyvalidate that its deliverable within budget and scope. We helped a customer to scale back their overly complex requirement, and applied learn startup principles to test what customers wanted. Then we just built those features. We cut the cost of development in half!
5. spot edge cases which the designer may not have though about. Animations, permission dialogs and alerts typically fall into this category and are usually missed — or not thought about until the end of the project.
At the end of this process, the design would be a lot stronger, more deliverable and a lot less risky. Its the perfect time and seek the various approvals that go up the food chain in a typical business.
Other tasks for developers to reduce risk in the early stages
Besides working with designers, there is a lot of preparation work for the project that can be started whilst the teams are working on getting the designs validated. Mainly the focus is on :
avoiding the “Developer-Designer guessing game”( More on that in my next post)
establishing a team work flow for designers, developers and customers
so that any changes that come through during the project lifetime are a lot easier to process and manage without derailing the project.
Communicate and collaborate
As you can see, any place where silos exist between various parts of a process are always prone to risk. It requires a lot of management and meetings to smooth over the cracks and build interfaces. It’s best to avoid them from the start.
(This is part 2 of my series of posts about some of the things I have learned since completing my Udacity Nanodegree 2 years ago. If this is useful, you can read the first post in the series where I talked about the awesome tool SwifLint)
I recall a conversation I had with a school friend of mine who is currently hiring developers. He has interviewed 35+ developers in the past month — and has only hired 3 of them. When I asked what made those developers stick out, he said that those were the great developers in the group — and he only wants great developers who weren’t going to make it hard for his team. So what makes a great developer you may wonder?? Its these 6 things:
Characteristics of a Great Developer
Understands System Architecture
Knew Design Patterns
Understands how to write clean code
Thinks about the users they are writing code for.
Cares about their team.
Has a good personality and is fun to get on with.
In the spirit of this useful information — I thought I would spend a bit of time posting about app architecture. After finishing my nano degree, I must admit- I had fallen in love with MVC on IOS. That was until recently when I tried something new to sway my passions. ( dare I call it cheating?) Officially my new favourite way of architecting an app is now strongly in the MVVM corner (aka Model — View — ViewModel which rolls off your tongue like a ball of chewing gum)
but before I can do that — let’s talk about the architecture that started it all: MVC ( Aka Model- View Controller)
MVC App Architecture Overview
MVC is a architecture pattern where you separate out your apps logic into :
Model handles the data behind the app and all the methods that involve manipulating this data. Models should never be connected directly to views
View are responsible for the presentation of the data held in the models. The are typically reusable so you can use the same “template” to support multiple screens. There shouldn’t be any logic in there
Controller this is where the logic and intelligence of you app come in. Controllers are the bridge in the app between the models and the views. Controllers are responsible for a lot of tasks including:
Looking for changes in the data models
Responding to user requests for actions .
Maintaining the state of the various elements in the view
Apple have a great summary of MVC on their site which can go into more details if you are interested.
Ease of MVC in Xcode
Having previously worked on Android apps, and other frameworks for web — MVC has become a standard go to method for managing digital architecture. Entire platforms are written around it.
Apple has followed suit and has actually built the whole app ecosystem and its tooling around MVC.
When I first started learning iOS Xcode and Interfacebuilder seemed perfect and MVC was the perfect architecture to produce apps with it. One of the joys of programming in IOS has been the great IDE(Integrated development environment) that Xcode is in comparison to other languages and how much its helps developers to code using MVC.
It seems so logical:
Create a new file using the add file wizard in Xcode. Give it a name and tell Xcode it needs to be a subclass of UIViewController.
You build your UI as a StoryBoard in interface builder in Xcode.
Connect up the IBOutlets to the methods in your view controller, by Ctrl-dragging from the outlet to the method that it triggers/ or the reference it connects to.
Make sure you have your models setup nicely as their own files, and then you can do all the heavy lifting in your view controllers.
I couldn’t have been more wrong — even by refactoring your code into using helper files, clients or event using Swift Extensions and ‘MARK:’ syntax— you will invariably end up with the single biggest problem related to MVC which has been dubbed
“Massive View Controllers”
— with whatever app you do, you will invariably end up with a skyscraper load of view controller code. The largest challenge about using MVC is that the view controller simply does too much and becomes a bottleneck in development. As an example — the open source AnimeNow manages the large View Controllers problem by using 4 separate extension files to break up its UIViewcontroller.
Using extensions is a great tactical solution to solve the massive view controller problem — but the problem really sits within the domain of resolving it an app architecture level.
Large complex files should be seen as a massive anti-pattern, and result in difficult to change and understand code. They increase the amount of maintenance needed, and also result in it being harder to find the connections between various parts of the code. Even the overhead of keeping multiple files open in multiple panes results in slower development.
Most importantly MVC appears to break item 3 and item 5 of my friends list of what makes up a great developer. Large files are hard to understand, and hard to change. Its not clean and its definitely not respecting your team if this is part of your standard output.
MVC can work — but after discovering MVVM — I don’t think I will ever go back. More on that in my next post.
There is nothing better than spending some time to sharpen the saw —and improve the way that I code my apps. By finding new ways to improve the code quality, or efficiency in which I write my code — it pays off big time in being more productive and heck it’s even a bit more fun.
For this week — it was a no brainer. I was chatting with my friend Jane yesterday- and telling her about SwiftLint and her reaction was… “this is awesome” and you should blog about it now.. so here it is.
So here we are….
SwiftLint is one of the new standard tools that I now spin up at the start of every project. This nifty tool is one of the few that will:
Help you to write better code
Make sure that your code is readable and understandable to others who need to use your code,
and most importantly.. for those of you like me who are on a quest to get those Xcode warnings list down to zero — it encourages you to fix the code as you type and thus you have the weighty bonus of having your GitHub full of lovely compliant code.
What it does…
SwiftLint works by applying over 75 (and counting) rules which are roughly based on the Swift Style Guide.
The SwiftLint Rules
An examples of the rules that really helped me were:
Trailing_newLine — SwiftLint highlights and warns if you put too many whitespaces lines at the end of a class ( a bad habit I picked up- which is now happily cured) It shows up in Xcode as a regular warning when you try build.
The great thing about SwiftLint is that it’s super flexible. You have the ability to use
all the rules on your project
Some of the rules on your project
None of the rules on your project
Or even apply some rules to only some classes.
Heard enough ? Let’s try it.
How to use it
To install SwiftLint — you need to:
Install it on your Mac via HomeBrew as my recommended choice: brew install swiftlint
Add the following build script to your project:
if which swiftlint >/dev/null; then swiftlint else echo "warning: SwiftLint not installed, download from https://github.com/realm/SwiftLint" fi
Then start building with CMD+B.
3. This is the most depressing part of the whole journey, when you zero error project suddenly generates a massive amount of warnings and errors. Don’t lose faith — we will fix them soon.
Below is an example from a project I use regularly called SWIFTCSV ( a CSV Parser which I am working on porting to Swift 4) where I went from zero warnings and zero errors to ….
The great news is that SwiftLint has a superb command line tool- which can automatically tidy up some of the errors for you (eg trailing line spaces)
4. Open Terminal and go to your project folder by dragging the project folder onto the terminal icon in the dock bar.
5. Run `swiftlint rules` to see what rules you have applied to your project
6. Run ‘swiftlint autocorrect’ which will try and fix the most common errors that it can. For me — it fixed a whopping 17 files straight away.
The rest of the warnings and errors took me a mere 10 minutes, and I could already see the benefit for working with other peoples code, and also making sure that I play nice by giving others better code to use.
Is the tool any good ?
The tool was written by Realm, who have a wonderful simple to use database tool which I encourage you to try out. The team behind Realm have a focus on producing great Dev tools and the quality of SwiftLint is a great showcase for this.
I have reluctantly added another definition to my personal Swift glossary. Its an anti-pattern called “Haystacking” which is….
HayStacking — trawling through the variety of Xcode drop downs trying to find a variable or outlet that can you kind of remember the name of.
Like other anti-patterns it:
takes away the joy of coding
and creates bugs.
again is slooooow to do — especially if you are a victim of a Xcode SourceKit crash in the process
Problem: Too many options when selecting from AutoComplete Dropdowns in Xcode
I personally have found that Xcode:
has way too many options when suggesting autocompletes ( this has increased exponentially since it also started suggesting images) When I come back to an app, it takes me a while to remember what outlet was called what.
It takes ages to find the name of an IBOutlet that I want to update especially if there are multiple ways to call it. eg did I call it NameLabel, or FirstNameFieldTitle. I sometimes have to scroll back up the pages to recall what the name is, or sometimes use a storyboard open in a second pane which slows things down.
Sometimes I want to see a list of just the labels — and currently this isn’t possible ( as far as I am aware)
If you are an advocate of using ViewModels (and ❤️MVVM❤️) — then I find its also handy to not have to keep switching to another file, to make sure I have covered all the view use cases.
Solution: Add type prefixes to the titles for your IBOutlets to let Xcode help you!
Thanks to a few people reaching out and letting me know that the syntax that I am recommending is actually called “Apps Hungarian” or “Hungarian Notation” which was originated by ex-Xero PARQ engineer, and former chief of Microsoft Engineering Charles Simonyi ( he also was also the 5th space tourist)
My solution for above is really simple which is adding type prefixes to the title for each of the outlets.
@IBOutlet weak var namesInTitleLabel: UILabel!
@IBOutlet weak var lbl_namesInTitle: UILabel!
and Xcode suddenly becomes a joy when you ask to see the list of all the labels in a view.
Buttons Actions Vs Outlets is no longer a problem
One additional bonus I have picked up from doing this — is distinguishing an action from a outlet quickly even for outlets I hadn’t created. I noticed that people tend to name their UIButton actions and outlets similarly, which can cause issues.
I name all my UIButton Outlets with the “obtn_” prefix and the actions with the “abtn_”. This “double re-inforcement” has the side effect that I now never forget to click the dropdown to select the ‘action” in the dropdown when creating the action for a UIButton via dragging.
and again we can find the list of all the button outlets in one go:
I have built up a list of the following prefixes- which I find work pretty well, but if you chose to do something like this — make sure you have an agreement with your team/ company to standardise the prefixes that you use.
lbl_ — UILabel
obtn_ — UIButton Outlet
abtn__ — UIButton Action
vw_ — Custom View
sv_ — StackView
tbl_ — Tableview
act_ — Activity Spinner
Above has really made it so much faster and more enjoyable, and at least until Xcode finds away to bring out a list of only a certain set of classes when autocompleting. This simple tip above works a treat and makes working with Swift even more expressive and easy to use.
Edit: ( added after publishing in response to feedback)
From the comments, I now realise that its equally possible to add the __lbl as a suffix and Xcode will pick it up it in its suggestions. This is perfectly valid as long as you remember to add in the suffix.
@IBOutlet weak var refreshPhoto_obtn: UIButton!
2. Some people are frowning on this approach, as apparently Apple prefers you to append the full control name to the variable. The problem with this approach is that you get some incorrect suggestions included alongside the correct suggestions, which take up more time.
eg: using label, the Xcode suggestion will favour the wording which starts with “label” as the first suggestion. It also shows up the class name directly below the correct suggested outlets, which can also be selected incorrectly.
3. There are some people who suggest that devs shouldn’t use prefixes as Swift should read like English. I disagree on this point, I personally think there are enough examples where Swift has chosen NOT to read like English in favour of features/ speed.
eg: (completion:@escaping (_ passedResult:Bool)-> Void) is very difficult to fathom
Given that Xcode is currently quite buggy with its speed of suggestions, whatever we can do to improve the speed in which we code is worth trying. Hopefully Xcode will improve enough that its easy to identify all the labels/ uibuttons quickly within a view controller, however until then — for me at least, prefixes are my preferred solution.
There is a multitude of app analytics platforms out there. They all have their strengths and weaknesses and can often be the difference between an app succeeding and failing. One of my favourites has got to be Fabric Answers which was created by Twitter’s Fabric team. This team has since been merged in with Google’s Firebase team — but both products continue to run and in many ways, Fabric’s tools are still a lot better than Firebase.
Why I love Fabric
In short, it’s a pleasure to use. It’s beautiful, its simple and it really helps users to understand quickly if their app is doing well or not. The UI is also incredible — its so beautiful that you forget you are using an analytics platform. The UI pulses and moves along with the data that its receiving in real time so your analytics actually feels alive. ( Much like the product that you are tracking)
A tour around my Fabric Answers Sandbox
Whenever I try out a new analytics platform, I always try and build a sandbox so I have an area to try out new things. For Answers, I integrated it into one of the Mac OS apps that I built.
This app is called Speedy for Jira, and I use it to download all the Jira Tickets that are assigned to me — and I can also log my time to each ticket all within one interface.
I restricted the data to show just a few of the users and one of my buddies so we can get some real-time data into the dashboard. I also updated the app version a few times so you can see how it tracks across multiple versions.
Here is what the default resulting dashboard looks like after a few days of fake data. Pretty impressive. ( and why are analytics dashboards always blue?? Are they trying to make Analysts into depressives?)
As you can see above it is really proactive at showing you what the key overall indicators are — and also lets you see the main things that make sure the app is operating effectively.
Also note that it differs a lot from a regular website dashboard as it contains things like:
Number of crashes
Adoption of new Versions
Stability of different version numbers.
Unlike the web, where you can keep tapping up the endless fountain of users, in apps world, you have to be a bit more cautious. Users who have downloaded your apps are already pretty engaged or are looking to be, so you have to make sure you do your best to keep them onboard with you. For most utility apps you want to make sure that users are using your app regularly. If they aren’t… perhaps you should be asking if you have the right features for your app. That’s why I find myself living in the retention reports. If that starts dropping it should start setting off 🚨🚨alarm bells🚨🚨.
As you can see above, Answers breaks the main audiences into the various key cohorts for you automatically. In my fake app data above — I only have one user who is in the green zone and has used my app every day for the past week. 3 people (in Red) just took one look at the app — and said yuck — and didn’t come back again. It looks like I should definitely be looking at the UI — and how easy it is to use as part of my future app plans.
But I noticed that the biggest drop off was that users, who were installing the app, were not continuing to use it a few days later. Looks like I need to dig into our engagement reports to find out why. Luckily Answers Analytics can help with this too.
Unlike Firebase Analytics which is really focused on funnels to manage your interactions, Answers focuses on optimizing towards events. It also comes with a great set of events out of the box. If you are running a game — you have a couple of key events set up for you.
The rule of thumb for most app analytics platforms ( and even Google Analytics Enhanced E-commerce for that matter) — is that you should try and match your events to the built-in events to get the maximum benefit for the analytics platform and save yourself a lot of heavy lifting.
For my app — I should really do a bit of work to think about what a conversion is for them. I have decided that since the app is quite new — I should focus on early-stage app metrics to validate.
Are people getting on-boarded correctly?
Are people using the features that I have built for my MVP?
Are there any errors that will frustrate users?
Even if I don’t implement any of the events, I can still get a wealth of data to understand what impact my app is having and whether I should look to trying to build features to grow my audience or find something more lucrative to do.
I tried everything and it was in the garden that I thought of an idea. What if I “re-potted” the project. For those that don’t know you repot a plant when:
“the roots get too big for the pot and the plant slows its growth or stops growing altogether” — Guide to Houseplants
Just like my xcode project…..
So when I got in I did the following steps which restored my project’s compilation speed and xcode autocompletion to down to a bearable second or two
How to “Re-pot” your Xcode project to make it faster in Xcode 8 for Swift 3
Create a new project in a new folder using Xcode 8.
Create a new Podfile project using pod init if you are using Cocoapods
Copy across your pod files configuration and pod install
You should now have a blank project with your pods included.
Copy across your project files (except test files, and supporting files like assets, Storyboard and App Delegate) in groups of 3–5.
For files like App Delegate I copied the contents of the body directly using Xcode
For Assets, I dragged the folder contents for it to the new project
Don’t copy across your new test files yet but just go ahead and just do a project clean and build.
You should now see that your project is blazingly fast.
Add the test files back in 1 or 2 at a time. Its here that I got a pretty horrendous set of errors. I noticed that I had to clean my project build folder (Hold down the Alt key and select Project-> Clean Build Folder) several times in this step of the process which I put down to some xcode bug.
Once you are done, copy the files over to your git repos and carry on coding!
Hopefully at the end of this process you will have a faster Xcode project for enjoying your swift 3 goodness. ( and maybe you have learned a little about gardening at the same time!)
Personally I hope that Apple will sort out Xcode 8 and get it working properly again with less bugs, but given their problems with the new MacBook Battery maybe they should focus on getting more people like us in to help them identify these problems so they can get rid of them for us.
Hope this process helps others out there…Happy Xcode Gardening.
Edit: As a by-product this also fixed the bug with Xcode Tests not running with the message:
New year = time to innovate. I am delighted to say that our Google Analytics(GA) implementation has just got a little bit smarter this week. One of my work buddies and I have rolled out our innovation project so we can easily track the results of development releases in GA, automatically. We call this Google Analytics Development Annotations(GADA) and its the start of our journey to making GA more powerful, faster and more useful.
Google Analytics Annotations are one of the most awesome and powerful features in the analytics kit bag, but the problem is that they are so often ignored. I personally love the features and power that come from them and it’s frustrating to see this crucial bit of Google Analytics so often skipped over. I thought I would create a quick guide about Google Analytics Annotations and why they are the proverbial missing link between WHAT google analytics tells you is happening on a website, and WHY it is happening.
We are kicking off a new segment on the blog, where we get advice from top innovators who can share some of their tips that helped to put their head above the crowd and got them noticed. Last week, we announced Ometria, the smart data marketing platform, would be the first shortlist for the Magento innovation award.
From an innovation standpoint, I was interested in deep diving into how Ometria had managed to make innovation work so well, whilst avoiding the modern pitfalls and be able to help make so much more money for clients.
I spoke with their CEO and Founder, Ivan Mazour(@IvanMazour), a serial entrepreneur with some really great tips on innovation. Here goes!