Archive - January 2018

See TSM4 by watching our affiliates

If you haven’t yet received an email inviting you to the TSM4 beta, then that doesn’t mean you can’t see it in action. There are many people who stream their goldmaking activities, and some of them have beta access. If you don’t have a favorite streamer or community person, we’ve included a list of our affiliates here. Hopefully between them you’ll find someone to your liking!

Dozerbob
TheLazyGoldmaker
Sheyrah
Phat Lewts
Arganthe (Portuguese)
Totemwerfer (German)

For those of you who’d prefer to listen to one of TSM’s own team members, Gumdrops regularly streams his goldmaking and answers any questions people have about TSM, including taking a look at new versions of TSM4 as they are released. Be sure to go check out his streams if you’re interested!

If you want to ensure you get into the beta as soon as possible, you can go ahead and sign up for an invite here. If you like what we do and want to support the continued development of TradeSkillMaster and also get priority access to all of our betas, please consider becoming a TSM Premium user.

Deployment System

In this blog post, I will be giving a behind-the-scenes overview of the new deployment system we have created and been using throughout the development of TSM4.

Why did we create this new deployment system?

The primary goal of all this was to make it quicker and easier for us to get new changes into the hands of our users, and give us the ability to control which sets of users get which changes. Let’s talk about the latter goal first. We currently split our users into 4 separate release channels: Internal, TSM4 Alpha, TSM4 Beta, and TSM3 Release. The ‘Internal’ channel is used primarily for TSM team members for testing the very latest changes. The ‘TSM4 Alpha’ channel was used during the invite-only alpha phase of TSM4. The ‘TSM4 Beta’ channel is currently being used for everybody who has access to the TSM4 beta. The ‘TSM3 Release’ channel is one which all of our users have access to, and gives all of our users access to the latest version (of TSM3) we push to Curse. These release channels can easily be changed and adapted as our needs change (i.e. as TSM4 goes from internal-only to alpha to beta to release). So, the goal of our deployment system is to make it as easy as possible to release new versions to the proper channel.

How do we do this?

We currently use Bitbucket to host our source code repositories. In the past year, they added a new Bitbucket Pipelines feature, which is a build and deployment system. Because we already use Bitbucket tools so extensively, and Bitbucket Pipelines integrates nicely with the features we already use, we decided to utilize it for our deployment system.

Whenever there is a new change made to our TSM4 code branch and we want to release a new version to our beta testers, we simply hit a few buttons within our Bitbucket repository to start a deployment. The details of what happens as part of this deployment is entirely custom. In the case of the TSM addon, this involves taking a snapshot of the current code, removing our internal files which we don’t want to be included in the release, writing the version to the correct addon files, and packing it up into a .zip. This .zip file is then stored on our server for the app to download and marked as the latest version for the appropriate channels.

Future Plans

Once TSM4 is released, this deployment system potentially allows us to do more regular, staged releases. For example, we can release new version to a smaller set of beta testers to ensure there are no critical errors before releasing it to our entire user-base. In the end, this means that we can get more high-quality releases out to our users on a regular basis with less administrative effort on our end.

The Design of TSM4

The TSM Team has been hard at work for a very long time to bring you the TSM4 beta. We wanted to give you some technical insights on what goes on behind the scenes. Today we’ll be taking a closer look at the Design of TSM4. H3ggers will be joining me to answer some questions!
I asked him three questions, and he’s been so kind as to offer detailed answers to them.

On a high level, what goes into setting up a UI from the ground up like this? How much of the old UI gets taken into account, and how do you decide what is best from a user experience standpoint?

Great question. So for any UI/UX work, it’s always good to start with research. Whether you’re working on a brand new product or something that has been around a long time (like TSM), you always want to start by investigating. You focus on what has been done, is being done, what’s working and what isn’t.

With TSM, I had a great leg up in that so much thought has already been put into it, especially in terms of what its features are and what users have wanted added over the years. So yes, the old UI was extremely important from the perspective of starting fresh. The old UI really tells a story about how TSM has developed over time, and why, what its strengths are but also what its weaknesses have been. So it was super helpful when setting out what we would and wouldn’t do from a “refresh” point of view.

As far as going from there and making decisions, I wanted TSM4 to not stray too far from its core competencies, but overall feel more approachable and intuitive. TSM is tricky in that it has always been perceived as a “challenging” addon, with a very steep learning curve. And a lot of that I think has to do with the fact that it has very advanced features comparative to other addons on the market (what other addons can you name that essentially have the equivalent of a file management system within them?). So just the scope of what you can do with TSM is a bit staggering for a new user and I think in some sense, always will be.

But that doesn’t mean there weren’t gains to be made that would help us hit our goals of being more approachable and intuitive. I think in TSM4 we were able to really think about how certain features would be organized and maybe move away from some things in TSM that didn’t really make sense (I’m looking at you ‘Features’ tab).

From a purely stylistic standpoint, what was your thought process on what TSM4 has come to look like? Why did you choose the colors, shapes and style that you did?

Stylistically, TSM operates in an interesting space. Historically, the look of TSM has developed through what I would call a “path of least resistance” mindset. We’ve added and improved upon features but haven’t really thought through the design outside of, “what sort of component do we need in order to achieve X/Y/Z, and where can we place it?” And while this has been done thoughtfully, with great concern for usability, I felt it had led to a somewhat scattered design aesthetic. So my first thoughts about style had to do with just keeping things clean and providing a less cluttered experience.

After that, it was really a matter of what sort of tone and personality TSM needs. I find that addons are a really unique design challenge, because you have to decide if they should align closely with the game’s default UI, or carve out a style all their own. With that said, I opted to keep a clean, modern aesthetic that wouldn’t diverge too much from what existed and wouldn’t be too jarring for our users. Down the road I think it would be cool to think about ways in which we could open TSM, stylistically. One of the early things that always impressed me about TSM was that it had a pretty robust appearance editor. Unfortunately, we rolled that functionality back for the time being due to the nature of the overhaul; I’m personally hoping we can bring it back (in a more structured way) at some point, and possibly even augment that feature with things like “UI skins”. TBD obviously 🙂

Are there any constriction points where looks and function conflict with each other? In such a situation do you make concessions, or look for a different solution?

Hah, oh yes! Design is always about balancing your stylistic goals against usability and feature requirements. The team and I had many conversations about certain design choices that might conflict with learned behavior and expectations from our users. I know that I’ve certainly conceded some ideas in favor of keeping a certain workflow or feature in tact.

This is one area where I really like to look at what our users are saying. There are so many unique aspects to TSM, and our users have all developed different ways of approaching certain tasks. Being able to engage with our community and test certain ideas out with them is really great and I hope that we’ll only continue to grow that process as it makes designing a lot easier.

That wraps up this first Technical insight into TSM4! We have more planned for you so if you enjoyed this content be sure to keep an eye on our blog!