I have to use SAS on a daily basis. Not by choice, but by necessity. Someone else made the decision to purchase and use this system, and I have to live with that decision. So I am somewhat trapped and here are the things that now infuriate me about SAS.
Getting the answers to SAS questions is harder than any other language I have worked with.
Stack Overflow has basically re-written the rulebook for how to find the answers to very technical questions online. Stack Overflow was founded in 2008 and by 2010 it had already changed how programmers work.
Still, the vast majority of typical questions about how to get things done with SAS, SAS macro language and SAS PROC SQL are found in the SAS community forums, SAS conference whitepapers, and really strange online documentation.
Forums are not well-suited to answering technical questions. An argument solidified by StackOverflows critique of Experts Exchange. Answers to very very common tasks on SAS questions require you to read EVERY REPLY on a 25 post SAS community forum post. They have a function to highlight the “right” answer. But that “right” answer frequently has to be contextualized by reading the conversation before and even after it.
So SAS does not have a QA site, they have a forum. They could adopt StackOverflow, they could get a stack-exchange site, they could use one of the many solid StackOverflow clones. So why doesn’t SAS have a proper QA site? Hell if I know.
SAS function documentation has very poor SEO. When you google a SAS function, usually the official page of the documentation is up first. But it is damn hard to tell if you are in the right place. First, take a look what happens when you google “php somefunctionname” for an example of what should happen:
Lets put ourselves in the shoes of the programmer who is seeking to learn something (lets call her the “seeker”). They are wondering “is this the right page? is this the right result? Do I need to search for something else?”. The php documentation SEO answers all of these questions clearly, letting the “seeker” know exactly what they would get if they click.
Lets look at the specifics. The title makes it clear: this is a page that describes explode from the php manual. The URL give you even more information. It shows that you are indeed in the manual, and that you are looking for the page about the explode function. The summary text is literally the description of what the function does, why you might want to use it and how it works.
Then lets look at the PROC SQL page.
First, the title is “support” what does that mean? Does that mean I am going to make a support request? Will I have to interact with someone? I am not sure. And the URL is even more confusing. It hints that it is part of the “documentation”, but mostly there is just a very long string of random characters. The text that is returned is random text that does not detail what the function is or does? There are several other results that I have to choose from, the content of which is all controlled by SAS and there is no way to tell which page is which, and what I can expect by clicking the various search results.
More problematic than ANYTHING else about the SAS documentation SEO. When I click the link, I am taken here. There are several different gateways to Proc SQL, but what I probably was looking for was this page. I have no way of figuring out what is the best page to visit.
So why doesn’t SAS have basic SEO working on their documentation? very good question.
But the real genius of the PHP documentation is that when you scroll down, you get to read all of the things that other php developers thought might be important when you were studying this function. So if you wanted to know, for instance, how to quickly do an explode and also trim whitespace, you can see that eye_syah88 answered that question 6 years ago.
Now granted, PHP is probably the best at doing SEO, since they are a web oriented language, built by people who know and care about SEO. But almost every other programming language is better than SAS at this, usually by a huge margin.
Missing very obvious usability controls
When you open a new library in SAS Enterprise Guide, and it has hundred of tables, they are not segmented by name-stubs. Instead they are just listed, which mens that you spend lots of time scrolling.
When you open a data file (a table basically) all of the columns are sized the same. If you want to actually read the column titles, which are frequently much longer than the default column size (and to not wrap) you have to manually reset the size. every. single. time. you open a new table. Could they have a “set all column sizes to 200 pixels rather than 50” as a global option? Yes they could. Do they have that option? No. Why not? Apparently to make me super annoyed with them. And to waste my time.
In order to see how many rows a table has, the quickest way is to put your mouse over the scroll bar. This will show how many total rows you have. But this has no commas, so it is very very difficult to read. When you let go of the scroll bar, the row count disappears. Or you can right click the table. Click properties. Click Advanced. And read the row count. But you cannot copy and paste the row count. Nope. In both cases, you can just “see” the row count. By default, most of the words in the interface are not mouse selectable, which means that you have to know just where to look to be able to select and copy text into the clipboard. “Why is this?” you might ask? Is there a reason for this other than to make their users life difficult? Good questions.
When you delete a table from the interface, the whole interface freezes. Obviously, something is happening in the background. And when it is done, the table selector hops to a different place? Why does it hop you might ask? Hell if I know.
Minor Complaints Major Time-wasters
It might seem like I am being petty. But small interface problems like this are taking hours of my time each week, and will ultimately add up to days and weeks lost in my life.
To address these problems, all SAS needs to do is hallway usability testing. The fact that these problems exist mens that SAS is not doing hallway usability testing with new users of its software, to work with large or complex datasets. If it were, it would allow you to set the default column size as an global option. It would show the number of rows in a dataset without requiring you to dig.
But they have done not of that, because they are stuck in a proprietary “meet the client, charge the client” paradigm that died for normal software languages 10 years ago. They only reason SAS has survived is that they work primarily with statisticians rather than programers. Modern programmers are used to better interactions with their software language makers, and they do not tolerate this level of crappy documentation, QA or UX anymore.
I would advise SAS to start porting commonly answered questions to stackoverflow. There should be no issue that receives lots of traffic on your user forum that does not have a company-written question and along with a company-written answer on stack overflow. Same thing with very popular whitepapers and blog posts. I should not have to dig for the right answer to very simple questions that thousands of others have asked before me. SAS needs to fix the interface issues that I am bringing up here, and then they need to do informal “play testing” of their interface for novice data scientists to explore large datasets.