Tenon.io December webinar is now online
Karl Groves: …We’re live. All right. This is interesting. This is my first “Hangout”. I did a playing around hangout with Billy Gregory who is the other half of the “Viking and the Lumberjack”. Billy and I played around with it and I thought I’d be smart and I would do one of these with hangouts and for Tenon and look what happened. My Google App’s account tricked me.
Let me go over here. I’m going to share my screen.
Karl: There is a actual chat tool box in there, comments or something like that. If you guys have any questions or anything like that along the way we’ll do that. I’m assuming everybody can hear me?
All right, cool. This is the “Tenon” home page. Hopefully you are aware of that. If any of you aren’t Tenon users that’s OK, because I’m going to go through the entire process of logging in and all that stuff. Which is, I’m going to log in.
This is a fresh account, completely fresh account, it’s my test account. This is what you see when you first log in and when you first create an account. I come in here at the bottom and no I won’t ask you to upgrade. For a lot of people one of the things that they need to do first is they need to get their API key.
We have a lot of people who use external plug-ins like, Joe Dolson’s “Access Monitor” for instance. Joe Dolson’s Access Monitor requires you to enter your key. One of the things we get a lot of people asking questions about is “where do I get my key?” it’s labelled here on the left and it says API key.
You can go there, you get your key and then you can use that with any of the third party tools that exist out there. The Grunt plug-in, the Gulp plug-in, the Open Scholar plug in, like I said, access monitor, any of those sort of things.
Let me go over the user interfere a little bit really quickly to get everybody familiar with the Tenon user interface. The dashboard is where you go when you first log in. It’s going to contain a high-level overview of your performance across all of your different projects and all the pages you’ve tested. As we see here, this is a brand-new account, there’s no information on it.
“History” would be a running log of all the history of all the tests that you’ve done. That’s good. Then we have projects. “Projects” would be a list of the projects. We are going to go over that. “Profile” is your profile. You can add your name. I’ll write my name here, Joe Schmoe. I can’t type. It gives you all sorts of information about your account. It will give you your progress.
Right here it says you have used zero of your plan 50 calls, because, like I said, it’s a brand new account. “Account notifications” give us a list of the notifications of all the emails that we’ve sent. “Password” is where you change your password. “Address” is your address.
I’m going to go through here for settings and API settings and applications. “Settings “is going to be basic profile settings. This has your date format. You can choose any of these optional date formats for any of your update information you have.
Your time zones, so it localizes to you, to whatever your time zone is. How long you want to time out to be, your session timeout, up to a full 30 days. Your number format. Of course, you can subscribe or unsubscribe to the mailing list here.
I would say that I recommend, if you don’t want mailing list stuff that’s cool, but subscribe to the updates. This is where we give information about system updates, change logs, stuff like that.
Next, I’m going to get to the “API settings” because these are really, really important. If I go to…local host, [indecipherable 4:42] , documentation…There’s some documentation here about the API itself.
Right now the documentation is only for the API. We don’t have a lot of documentation on the website interface which is unfortunate. That’s one of the things we hope to beef up here in the next quarter.
Throughout this, what we’re going to have is, we’re going to have some information on the request parameters. The request parameters are going to be listed here. They are described in long form API documentation style format. I’m going to go through some of these because these are going to be really important for customizing your settings.
One of the things that’s interesting about Tenon, is these two request parameters here, “Certainty” and “Priority”. What’s cool about Tenon is that we try to avoid false positives. They’re are sort of the bane of accessibility testing tools. You can go to the web and list all the way back to 2003 and you hear people talking about these things called false positives.
False positive is anywhere where the product creates a result that’s inaccurate based on context or whatever. We are particularly sensitive to that. We don’t want to create false positives. That doesn’t mean we’re perfect but it means were very sensitive to it and we want to try to avoid it if at all possible.
We create this thing called “Certainty score.” It’s basically a subjective interpretation of how certain we are that something is an actual issue or not. Something that has 100 percent certainty, it means the tool is a 100 percent certain that we have an actual issue.
Let’s say something like a missing ALT attribute is something that we have a 100 percent certainty on. We know for a fact, that there’s 100 percent certainty on something like that.
Other things maybe not so much. For instance, we had — we disabled it — we have a test here that look for implicit headings. The implicit heading would be something that had bolded text. The only sub tag in there would be bolded text.
That only had a 20 percent certainty. As a matter fact, we found in practice it was creating so many false positives that we disabled the test altogether.
Anyway, what’s cool about this is you can set your default settings here to only test for anything that has 100 percent certainty. That way you would know without a doubt everything that Tenon had done would be certain.
This is definitely the kind a setting you would want to use under two important scenarios. The first scenario, would be something where you’re using a continuous integration. In a continuous integration scenario, you would be looking to fail a build for accessibility problems.
You wouldn’t want false positives in there. You want to set it to 100 so you didn’t get any false positives.
Another scenario would be if your team was new to accessibility. The problem with tools like this is that people tend to believe the results on their face without any further scrutiny. That’s great. I mean, if you think about it, why would you want to pay for a tool that didn’t have a high degree of reliability.
The reality that sometimes the tools do create false positives, and we need to avoid those. In that case, if you were in brand-new to accessibility or your team is brand-new set to a 100 until they get their feet wet, until they get an understanding of it.
The next one is “Priority”. Priority is also important. This uses a proprietary algorithm that I developed that takes into consideration a number of factors to help to rank some of the accessibility issues. It ranks them on a protest basis.
What happens is, every time a test-run runs we get all of our results. Then, the priority algorithm ranks each one of those things according to a bunch of things, like ease and speed of repair, impact on the interface, impact on the user and so on.
This is 0, 20, 40, 60,80, 100. You can say that something that had 100 percent certainty would be the kind of thing that had high impact on the user and a very easy repair that had no impact on the interface. All ALT attributes for images will be really hot because it doesn’t impact the interface at all. It does have a high impact on the user. It’s going to have a higher priority.
In practice, you probably don’t want to set this any higher than 80. What we’ve seen historically throughout our data is that you will see a lot of things hovering around that 80 mark, maybe even between 60 and 80. You’ll see a lot of important things hovering around there. You’ll want to set it here. At your maximum would be about 60.
This one, this fragment parameter tells us whether or not what you’re testing is a part of a page, rather than an entire page. This is important because this tells certain tests to run or to not run.
Remember, in this case we’re talking about our profile settings. You’re probably going to want to say no here. If you knew, for instance, that you were only going to be using say, the grunt plugin and you’re going to be testing partials or template files, you may want to select, “Yes”. For the most part, you wouldn’t want to do that.
Importance goes into the prioritization algorithm. You could say everything you are testing has a high importance by selecting three. Generally speaking, you’d want to do this on a per-project basis.
The last couple of ones are probably a lot more easy to understand. Default level is whether you want to test for WCAG A, AA and AAA. I have a blog post on my own website about understanding WCAG level. I heartily recommend that people read this blog post before simply wanting to select AAA only.
The reason why is because the levels here don’t directly correlate to importance. The way that WCAG one was, they had a priority level. It was basically based on user impact. In WCAG two, they changed things around a little bit. You still will find things that I would consider easy to fix and important for accessibility in level AA.
If you’re in an organization that’s concerned only about compliance, then historically, the legal compliance level that is mandated most, accessibility settlements, is level AA. I wouldn’t blame you if you chose that. Leave it at level AA for a bit. You may find some things that you’d like to fix that are AAA.
These last two radio button sets are “Reference info” and “Store results”. In Reference info, do you want reference information to be returned in your results. I would suggest yes. Especially if you are new to accessibility.
Store results. Whether you want the system to store results. That’s a yes or no. By default, it’s going to say yes. The reason why you would want to do that is so you could get access to archive test results.
User agent string is going to be the browser user string that you want to have returned in your results. This doesn’t do anything magical as far as testing is concerned. It would be more of a case of if you had a system that was sniffing for user agency, maybe you’d want to have one to pass through here.
For instance, let’s say you wanted to test your responsive designs. You could actually pass through your brake points into these settings. You would get results based upon those view port changes being made. The default one is 1024 by 768.
We use that because there are a lot of people with low vision who tend to use resolution about that size. We do some testing based on view port sizes and stuff like that, so we use that setting. You can put whatever you want in there.
You could put that delay in there in terms of milliseconds. 2000 seconds would be two seconds. That would be your default delay. I leave that blank because again, this is my profile setting. I’m going to set this. This is set globally for me now.
Every time that I do testing, if I don’t change any of these settings, it will run under these defaults. As a matter of fact, now that I’ve done that I’m going to go here and set that to 60.
That’s my default settings.
What’s cool is if I go into my projects and I want to create a new project, I’ve clicked that project link on the left. I’m going to click here, it says “Add new project.” What’s going to happen is, if I scroll down to project settings, this project has inherited all my settings from before.
Let me go ahead and create a project. This project is going to be called “FORTUNE 500”. I can give it a name. This is called the FORTUNE 500 home pages. I can give it a description, “This is a project to test fortune…” I’m going to go here. That’s not what I wanted. I have this list stored up.
What’s really cool is if you know every single URL of your site, you can dump a list of URLs in there. I have this text area. It says “Add, remove URLs for testing”. I’m just going to paste those in there. You can paste any amount of gibberish in there, and what it will do is strip the URLs, so you don’t have to do one every line or any of that sort of stuff. You can put them in there.
Next is do I want to test these URLs now. Of course, I’m going to say yes. That’s almost always going to be yes, so I’m going to say yes.
Do I want to monitor these URLs? This is really cool. What will happen is, Tenon will periodically check to see if any of those pages I’ve put in here have changed. If they have changed, it will retest them.
Unfortunately, it’s not a terribly intelligent test for changes. In other words, if you do a lot of A B testing or if you have ads that get displayed or something like that, it will retest them. What it’s doing is determining whether the Dom of the page has changed. Of course under A B testing or advertising, that would have changed, so it would trigger the retest.
You can monitor the URLs doing that.
Here’s all of our same identical settings from before. Down here is, “Do you want to set this as your default project?” I’m going to say no here, but I’m going to describe exactly what your default project does after that.
If you notice when I first got here to this projects dashboard, I already a project here, called “Default Project.” As a matter of fact, you always must have one default project because at the request time, if you don’t have a project as part of your request, it will dump it into the default project. That’s exactly what this thing does.
If you see at the very top, this analyzed now thing, will allow me to run a test, and doing that will allow me to analyze a page now and it goes into the default project. I’ve tested this page and gotten my results.
This gives me a good opportunity to go ahead and show you guys what the test results look like. Now keep in mind that the website, the Tenon website that we’ve been looking this entire time is just a client of the API.
As a matter of fact, if I go here and I go to “Postman”. If you don’t know Postman, it’s a really awesome tool. if I go here to Postman and I enter my key which is here, and I enter a URL and I enter, http//:www.google.com, I’m going to do the request here and I’m going to get my results.
This is the JSON format that you are going to get from the API and this page here is just a prettified version of that JSON format. We have only put a limited amount of the data in here. I’m going to go through and show you all the other nifty stuff in the JSON format but let’s face it looking at JSON isn’t exciting.
It gives us our stored test results and then we have a couple of things that we can do. First is, we can just download the CSV. This gives you a CSV that you can use, if you are a Q analyst, you can log into your bug tracking system and attach the CSV, and say, “Here is all the issues from testing this page,” or you can test multiple and get all the information.
We have here our stored test results that’s coming from the JSON request. At the top is how many issues were found, the URL and some other information about the page size and so on. The left graph shows us the number of tests that were run and how many passed and how many failed.
We see here that we’ve had 7 tests failed out of 62 and in this graph here, is a pie chart that shows us, the relative amount of failures from the results that we got. I don’t know how in the heck I did this with this zoom business here. I’m going to go ahead and close that. I hate when I do that. Dashboard, there you go.
Matter of fact, let’s take a look now at my history, go back in the history and I can view my results. Back to the results here. This is the result list in this table here. The result list has two important things on the left, the first one here is of course the code snippet it that we found that had the accessibility problems.
This is the actual HTML from the Dom, and this trips people up sometime because they go, “Hey, that’s not in my page.” They find out the job description or something else has injected it. The next thing that’s important here is the test ID.
This is test ID nine. I want you to keep very close attention to this because if you ever are using Tenon and you find a result that you disagree with and that you think is bogus, you think it’s a false positive, you think it’s not really an error, I want you to do one very important thing for me.
Tell me the test ID, and tell me why you think it wasn’t an issue because again we really care about false positives and stuff. If it is bogus to you, it’s probably bogus to somebody else and we need to hear about it.
The next thing that we are going to see here on the right-hand side under the description column, it’s going to be a lot of the information about the issue itself. First off, whether it’s an error or not and we say error, errors in warnings are going to be shown here. How do we determine that?
We determine that anything with 80 percent certainty and above is going to be an error and anything below 80 percent certainty is going to be a warning. Kind of arbitrary, some people would say 100 percent or not. We think that these need to be called out as errors if they are 80 percent and above. There is only rare chances that they are not actual errors.
The next one is the priority score. Remember I said that each of these priority scores are normalized, they are normalized against all the other issues on the page. This one is probably the highest, it’s got a priority of 95, I doubt we are going to see 100 down here. There it is. There is our 100.
Let me describe why this is 100 because it’s got blank link text. Now there is a title attribute on that but the title attribute is not visible to people who have motor control problems, who use something like dragging, but we also give you the line number and the column number. This is on line 11 and the source. We have the test here for what the issue is.
Let me go to one of this here, if we click on “Recommended fix”, this takes you to a full best practice entry for this. It says, “Provide all attributes for image element.” It gives us a description of the test itself and it gives us the remediation guidance.
This is pretty sparse, add an attribute for image elements that can be fleshed out a little bit. Here is our prioritization information. It tells us we have a user impact that’s high, or paired that’s high impact on the interfaces is done and so on. That’s the raw score. That got normalized at 95 percent.
We also have code samples. The first one is the bad code example. The next one is the good code example, and other information about the standards and guidelines and all that reference information that comes along with this. I hardly recommend perusing the recommended fix.
He recommended fix information some of it is a little bit of a cobbler’s child at the moment, where we need to be fed up. You find one that you say, “That’s not clear, it’s not complete, I want more information.” Shoot me this link here at the top, just shoot with the link forth and I will be sure to take a look, and see what I can do to make it easier to understand.
Let me go back to our projects. Our projects are listed here and if I go here to default project, it will take me to the dashboard for that project. Let me go over a lot of these things here. First off, the top information, the summary information gives us a listing of all the pages that were tested.
I have one distinct page. It’s one distinct URLs that were tested, it gives me the successful versus the unsuccessful. The reason why you want to know unsuccessful is you want to know if you’ve had any problems with some of your tests not working right.
Sometimes we have people try to test up behind a firewall that’s not possible. If they have a high amount of unsuccessful ones, then we might want to give them some help. Gives us average errors per page, average warnings here at the right, average issues, average certainty and average priority.
Down here we have two graphs for the number of issues, per kilobyte and the distribution of density. Let me log into the main Tenon website with my admin account, because it will give you a better understanding of what these things look like.
That’s what these look like, this is going to be a line chart, this when it loads up it’s going to be a bar chart. This is much more realistic, the depiction of information here.
We use issues per kilobyte at source code, because that’s a little bit more of a realistic description of the status of the website. If you had a page that was 10 kilobytes that had 10 issues, you’d have 100 percent density versus if there was 100 kilobytes of source and had 10 issues, it would be much lower. Density is a much better indicator than raw issue town.
We have this Tenon graph here. We have the bar chart, these are the number of pages at zero all the way up to the number of pages that had 100 percent. As a quick glance, the more of the bars that are on the left that are taller, the better that you are doing. If you get these last three here getting really tall, that particular project or that site, performs particularly poorly.
Down here we’ll see, this is the worst performing pages there. This is an important one. This is duplicate issues, now the duplicate issues table is an indication of how many times, we found the exact issue in your pages.
At a meta level, in this situation, we are looking at all of our projects, that’s not terribly useful because we are looking at all our projects and it’s not a good indicator. If you had selected a single project and then you started seeing a bunch of duplicate issues, then you would notice, that there was a lot of patterns that were repeating that we should stop doing.
These are again, like I said, duplicate issues. When I say that I mean the same exact issue using the same exact source code located in the same exact spot. What I usually tell people is, imagine I’m on the CNN site. This CNN search box then this little search affordance that they have. Let’s say there was an accessibility problem with that.
If we scan 10,000 pages on cnn.com, we would see 10,000 instances of that issue. That’s silly. It’s only one place in the code and that’s what we’d be looking at here. We could explore what’s going on there and find out what those are and then we could make a big broad important fix across the site. Those are duplicate issues.
Below that we are going to have issues by test ID and this shows us the specific issues that have the count for each issue as well. These are not the most common issues. These are actually all of our issues and we can sort by this and determine which ones have the highest incidence.
By percentage, the blank link test is the most frequent issue that we have in our site on down to duplicate IDs and so on and so forth. This is a good indicator at a organizational level what practices we need to stop.
Down here, that was the duplicate, sorry. These are the issues by test ID, there we go.
Down here is going to be issues by success criteria. You’ll notice here that some of the roles are grayed out. They are in a disabled state, because we don’t test for this things. This is one of the most important things that people who are new to accessibly testing need to know. Accessibility testing tools cannot find all of your issues.
If you look at some of this and if you are familiar with WCAG, you will see that it’s pretty obvious.
For instance, there is no way that for 1.2.9, there is no way in the world that an accessibility tool will tell you whether you are meeting the requirements for audio only information that’s live.
In other words, what they are looking for is if you have audio only information that’s playing live, do you have a proper alternative, which would be in most cases be some sort of caption or live transcript and so a testing tool is not going to do that.
There is a listing of all the ones that we do test, as well as how often. We found issues with those. How many distinct issues we have and what the percentages are of those? We go through here and we can download a CSV of that information.
This is at a high level of all of our information on the website itself but let’s talk about some of the other things that you can do. For one thing, the API itself as I mentioned before, extremely powerful the website itself is a client of the API.
This is what our API response looks like. If you are not familiar with JSON, that’s OK. You will see here that a lot of this same information, that we saw in the user interface, is here, but we do have a couple of other bits and pieces that can be used and added to this.
“This is great. How can we use this?” You can use it in Joe Dolson’s Access Monitor. If I go to a11ybuzz.com, Joe Dolson has done a really awesome job of creating a plug-in that goes into word press website.
You can hit this button to do accessibility check if we go to a post and we go in here to…Let’s take a look at this. We have a post here that we want to check, Joe’s done a great job here. You go ahead, it’ll check the page itself, it will check the information in your post. It’s going to see here that there two unlabeled form deals and unlabeled image.
I run the check, it’s going to go out, get the results and here you go. It tells us the post may not be posted. This doesn’t meet our minimum requirements, give us the information right there. Let’s say you are a developer, you can go into use this as a Grunt plug-in.
If I go here, this is a Grunt-Tenon demo. Now I’m going to through some of this. If you are not a grunt user, it’s pretty awesome. I’ve vacillated a little bit between going from grunt to Gulp and back to Grunt personally, but this is great because what this does is that we can run a bunch of different checks on our code.
I almost always, I’ll use this task which is JS hint. Let me see if I can zoom in on PHPStorm. JS hint is great, because it does a quick syntax check of your java script files and I love that. It helps me from making bone-headed mistakes that I have to fix later.
JSON lint, it will run a linting, checking of my configuration files so on and so forth. There is other things I can do with Tenon itself. What I’m going to do here is that I’m going to show the Tenon task.
This was done by, I think this was done by Ed Garci and if I mispronounced Ed’s name I apologize. Ed created this Grunt Tenon client, and so this is the Grunt plug-in that uses Tenon itself as a client. It lets you run the checking on your pages as you develop them.
What I can do is I can give a folder full of source files and it will test them. Simple as that. If I have my projects here and here is my source files, I have the regular old website right and my Css and all my other assets carved out here.
I can give it a configuration file, so Tenon RC. If you recall from earlier the API settings that we have talked about before, the Certainty, Priority and all that sort of stuff, we can put all those here, which is cool.
The other thing that Ed did was, he created a filter. In other words, if we have some tests from Tenon’s that we don’t like, you can filter them out by putting their tester id here [indecipherable 36:32] .
The other thing that I can do is you can run your configurations inside of the task itself and so this is the whole Tenon task here. In this case, this is going to test them all under default setting. If I wanted to do responsive testing of my iPhone responsive design, I could put that there and put that here for the tablet.
Check this out. I am going to go to terminal and going to run Grunt Tenon. What’s that is going to do is that is going to the Tenon web servers, it’s going to get the results and it’s going to test all this pages, and give me all the information about them.
When it’s done it’s going to bark at me and tell me how many issues it found. There we go, so the task failed. That’s the problem that we failed our task and we’ve got our issues. One of the things that I have done is that I have commented out the files to save it, but he also has a task here where we can save all the JSON responses into this file here.
The other thing you could do though is there is a number of other plug-ins that are out there that use Tenon. One of those is this one called Tenon reporters from Justin Stockton. One of the things that you could do is that it will return HTML, it will be a fancy little HTML page x unit.
If you are using Jenkins or Hudson for your continuous integration, it will do that and then I think he’s got csv in here as well. What you could do is actually instead of putting it here you could you could pipe that through some out through one of this reporters or something like that.
Another thing that I have added to this…There is another thing that we’ve done, and that is, I can add it as a Grunt watch task so any time my HTML files change, Tenon will test it. Another thing I did is I added as a Githook, so as a Pre-commit cook, it will run inside here as a Githook and kick back if there’s any problems.
Like I said, there is a number of other node modules here. This is the API client that Ed built both his Gulf plug-in and his Grunt plug-in. This is the node module that Justin wrote for his recorders, and this is another Grunt Tenon which is done by guy named Andrew Razorfish.
This is a pro-tractor testing plug-in and it also uses Tenon. Finally Grunt Tenon inline was done by one of our developers. What’s cool about this is what the Tenon inline task will do is that it will inline all your assets. Let’s say you wanted to test your css, well, it would inline the css file into the HTML file, so you get that final rendered Dom test of the page during the testing.
Then Travis. The other thing that I did [indecipherable 40:39] yeah, there we go. Here is the Grunt Tenon demo. What I did is I added this to Travis CI which is a continuous integration tool.
I created my Travis file here. Here is my Travis file and it installs on my node modules and installs on my [indecipherable 41:07] dependencies, then it runs the Grunt task. Here is my output.
We have all of these individuals specific work flows covered. We have the website handles are QA engineers or any of our, may be compliance folks who want to do testing but they don’t want to get their hands dirty with any of the API stuff.
Our QA engineers can use the API and tie that into any of their stuff. They run Grunt task or any of those sort of things. As a matter of fact, I can run this as part of Selenium. I’m running out of time. If this takes too long, I’m going to bag it.
Karl: I’m going to bag that, the Selenium example is…I have that on YouTube I think.
Karl: We’ve got 10 minutes left. There is one more thing that I want to do and that is to talk a little bit about testing only to pieces of code. You can simply grab a piece of code from one of your sites, one of your pages and test that OK. You just copy that, paste that in there it will automatically determine whether you have code or a page in there. It will test them.
One other thing that we have a challenge with right now is how to test things that require authentication and how to test thing that are behind a firewall or something like that. Right now that’s pretty much it. You going to grab a piece of code and you are going to come in here and you are going to analyze it.
We are working on a couple of things in the…Leading you into a segue, and that leads me to the segment of the road map for Tenon. The road map for Tenon is pretty exciting. We have a couple of things that we are getting ready to release in the relative near future, Christmas break, Christmas vacation for work, affording more time to some of this things.
The first exciting thing that we are going to have is a reports API. All of this information that you see here, you’ll be able to go and grab from a reports API. You pass at your API key, you can optionally pass in your start date and end date and then the type of report that you want.
If the type of report that you want was the information here in the summary, you pass and type summary and you get that JSON. You can integrate that into anything, any other reporting dashboards that you may have. Some sort of business intelligent stuff you can pass in and you can also pass the project name as well.
The next thing that we are working on is a project’s API so right now the only eternally facing API we have is the test API. What you will be able to do is you will be able to create a new project, and you will be able to submit test against that project immediately, as well.
For instance, if you are going do…Let’s go back to our Travis example. If you wanted to create a new project for every single build, you could do that. You can create that new project with the API, then you run your build that does the automatic testing and then that information is returned back to you in your test or you can get back at it from the dashboard.
That’s also going to include a spider. I’m not a huge fan of spiders, I think of them as sort of very broad hammer that you are going to smack something with. At the same time, there are people who work on websites that have massive amount of content being added all the time and so how do you monitor that kind of stuff?
Spiders are your only choice if you have all these content being added from outside of your development environment, say, the content management system.
That’s another big fun thing that Ace and I are working on, she virtually right now. That will be done very shortly. Another thing that’s going to happen to those of you who want to test on your development environment but you can’t expose that development environment to the outside world, we are adding a tunnel.
That’s going to be called “Tenon tunnel” and if you watch on our GitHub repository, you will notice it when it comes up but the tunnel is going to allow you to create a reverse tunnel, an SHH tunnel connection that’s a single connection between you and the Tenon API.
What’s really cool about that is you create the tunnel, you run your tests and when you are done running the test, that connection is killed off immediately. That connection will never be reused, that resource dies immediately and is gone forever.
That’s another important feature. If you’ve ever used anything like ngrok or LocalTunnel.neat, it’s the same kind of thing. The only difference is that it’s authenticated directly from your specific API key.
If you don’t have a key, you can’t even connect to this. So we don’t even have any sort of issues with outsiders connecting to the servers.
That is it. I know that this is a lot of information that was getting dumped all at once. I’m going to cast future webinars in the coming weeks. They are going to be specific to a specific type of task.
For anybody who uses Joe Dolson’s Access Monitor, we’ll be doing a webinar for that. For the grunt and Gulp stuff, we’ll be doing a webinar for that, for Selenium, any of that sort of stuff.
The last thing I’ll leave you with is if anybody is interested in elaborating on one of this things let’s say a plug-in for Adam, some blind text, or something like that, absolutely enthusiastic about supporting things like that.
Our goal with Tenon is to facilitate testing whenever you do your work. we don’t believe in the idea of having to go to an external product to do that. As often and as well integrated into your products that you already in your day to day work and that’s where we want to be.
So that going to be it from me and a number of you submitted questions ahead of time for what you like to see in here. If I haven’t answered those or I’ve just created more questions for you let me know.
What I will do is, I will do a prerecorded answer and post that on YouTube as well. This one as soon as I’m done with it is going to get uploaded to YouTube but I’m not going to publish it until it’s fully captioned.
I will caption that, I anticipate the length of time of that to be about a week, but I will email everybody who attended and let them know about where that is and I want to thank you all for showing up and see you next time.