Are you a coder or application designer that has some cool things you want to contribute to the Store Locator Plus project? If so there is a Trello project and a Slack channel that I have started using more frequently to communicate with the developer community. Send and email to info@ or use the Contact Form on the CharlestonSW.com website and request and invite. You will be added to both services where you can not only see what is going on with future Store Locator Plus development but share your comments, code, CSS patches, designs and other talents to make Store Locator Plus the best locator possible.
I have been working on filing a provisional patent for the past 2 days. I am not talking about writing the actual patent, that took over a week. When I say I have been “working on filing” for 2 days I mean the actual “simple” process of filing the already completed patent via the USPTO online filing system.
The quaint USPTO’s web app is referred to as the “e Filing System”. Remember when “e-Whatever” was cool? That meant you were doing cool online stuff with the interwebs like “e-Commerce”. Maybe it is still cool to refer to anything you do via the web as “e-Something” but I’m pretty sure nobody calls their website their “eStore” or their “eBrochure” these days.
And by “quaint” I mean outdated, non-functional, and generally useless.
Now I know the USPTO goes back a few years. They started way back in 1871, just before Al Gore got his first computer and started designing the Internet. Thus I can understand what they are trying to achieve with the user experience throughout the site. They clearly want to mimic the classic look-and-feel of the original Internet to give the entire site that sort of “reminiscent of the good ol’ days” feel.
The horrific color scheme, complete lack of use of white space throughout the site, pages with nothing but lists of links, and 37 menus per page are all great design patterns of the early Internet. Sure it makes the site difficult as hell to navigate, but sometimes you need to trade usability for really great marketing and branding.
I do think they missed some opportunities by leaving off the scrolling marquee. I definitely saw a few places where blink text could add to the experience. I am also fairly certain my browser is not setup properly because I did not see very many animated GIFs on the page either. But hey, nobody is perfect. I’m sure they will get those things implemented next week.
Ultra Secure User Registration
Now, to get started with the USTO advanced electronic filing system they STRONGLY recommend you become a registered user. With some forethought an ingenuity they actually made this a fairly simple process. You start by filling out a Customer Number Request PDF file and FAXING it to the USPTO Electronic Business Center.
Once you have that you can then proceed to Obtain a Digital Certificate by downloading and executing the PKI Subscriber Agreement, completing the Certificate Action Form and then MAILING the original form (no faxes or copies) to the Commissioner for Patents.
I am really glad they did this. I, for one, think it is WAY too easy for people to conduct business online. If everyone that ran an online business would start requiring people to both FAX and MAIL (I’m talking Postal Mail, aka Snail Mail here… not that spam-infested email thing) documentation to obtain a login then we would ALL be better off. Just think of how much less spam, phishing emails, and viruses there would be online if everyone was required to prove they were serious by going through this process.
Bravo USPTO on helping make the Internet a more secure place to conduct business.
Maybe NASA, the Armed Forces, and other branches of government will follow your lead and make their systems more secure when it comes to online transactions. Lord knows their 100% online registration and access systems for government contractors attract the scum-of-the-internet like an infested wound attracts tsetse flies.
Modern Java Form Fields
Luckily the USPTO has created an online filing system that is a little less historical than the UI design. Their modern process moves beyond the early days of the web and brings us past the days of animated GIFs and fully into the World of Java apps. Thankfully they saw the future of web applications and did not burden us with browsers that can’t handle things like filling out simple online web forms or uploading files. Lord only knows that sort of thing NEVER works cross-browser.
Thankfully the USPTO site forces me to download the Java Runtime Engine plugin for my Chrome 35 and Firefox 29 browsers. Heaven knows where I’d be surfing the web these days without having a full Java engine at my beck-and-call every time I needed to fill out a web form or update a file. Thank you USPTO for having my back.
Standard PDF Support
Thank GOD they support standard PDF files. You don’t know how many times I’ve been bitten by the hassle of dealing with NON-standard PDF files. I mean, it is not like PDF file formats are a proprietary file standard or anything. If everyone did this I definitely wouldn’t need to have those 37 different PDF readers on my system. Phew, another good save USPTO!
Not to brush off the fact that they also support the modern .ZIP compressed files, mega tables (when normal tables just won’t do), and the ever-present etc submissions. But hey, let’s face it standard PDF files are a big deal.
Java Apps That Shine
OK, enough of the sarcastic wit. In reality the USPTO does have one thing that is useful here. They do allow the normal scum-of-the-Internet, people like me, to file a patent without having to fax and mail documents to become a registered user. That is truly a good thing. It allows me to gain access to the modern forms interface that would only be possible with a solid Java app like the one they have running on the site.
The beauty of the Java interface starts to shine right from the first form. Things like required form fields marked with a asterisk, helpful information circle graphics with off-color backgrounds, and compression artifacts in inline graphics would not be possible with the basic forms system and CSS of vanilla HTML. I don’t think the random mix of proper-case, uppercase, camel case, and mixed case would be possible – at least not without a TON of extra work – with standard HTML. Just take a look at all this modern form interface elegance that could only be viable by standardizing on Java forms!
Add another bonus point for USPTO security. Thankfully they have made sure that all form inputs are cleared whenever you go back to a previous form. I’m not talking about using the back button on your browser here, we all know better than that, I mean baked RIGHT INTO THE APP. How cool is that? Fill out a form and miss on of the 39 steps including 12 hidden checkboxes and the form is automatically cleared for you to start over. Don’t want to influence you with past answers, after all they were WRONG the first time you filled out the app.
I also like the fact that the tabs are completely locked down unless you are on that particular step of the process. It is a huge security hole to allow people to just jump around all willy-nilly like and navigate to any part of the interface. If you are on the step where you are supposed to be reviewing your documents that is ALL you should be doing. It has been proven that people are easily distracting and being able to click a tab for a previous step only increases the likelihood of distraction. Thankfully the USPTO prevents that and makes sure that no matter what tab you click you always are shown only the current page you are supposed to be on… often cleared of all the data you were entering just to ensure you start with a clear mind!
A Lesson In Usability
In all seriousness, I truly appreciate what the USPTO has done here. It serves as a shining example of how to serve your customer base. Next time you are about to embark on a new web interface design, PLEASE visit the USPTO site. Pretend you are someone that is wanting to file a new patent and go through the process. Take note at how easy the interface is to use, how many times the user starts cursing, pulling their hair out, and throwing their mouse across the room. Or take the shortcut and try it on a tablet, which will definitely bring you to the final analysis a lot faster; I reckon within 3 minutes of doing so.
Then take a deep breath and think about your new project. Think about all of the things you DID NOT do to your customer by avoiding all of the user experience elements the USPTO brought to the table.
Go back to your design and think… “how can I make it simpler”.
I know it is difficult to see a user experience that you’ve been working with through a “fresh set of eyes” , but take the time to do so. Introduce new people to the experience and listen to their feedback. I’ve been doing the same thing with my site and every time I go through the process I always find something that I realize “wow, that is a pain in the ass” and try to make it a better experience for the user.
At least I can take solace in knowing no matter how convoluted my user experience is on my site or in my products they are light years ahead of the multi-million-dollar EFS system the USPTO cobbled together.
But hey, they do recommend IE 4 and Netscape Navigator 4… maybe I should go back and test with the recommended browser versions. Maybe I’m missing something! Does anyone have a Windows ME computer I can borrow?
If you’ve been following along since my WordCamp Atlanta trip this spring you know that I’ve been working on automating my WordPress plugin development and production process. If you missed it you can read about it in theWordPress Workflow and WordPress Development Kit articles. Since I needed to patch some basic CSS rules in my Store Locator Plus themes, these are plugin “sub-themes” that style the store locator interface within a page, I decided now was the time to leverage Sass.
Sass Is In The House
It was one of my first sessions at WordCamp Atlanta and I KNEW it was going to be part of my automation process. Sass is a CSS pre-processor. Store Locator Plus has its own “theme system”, a sort of plugin sub-theme that lives within the WordPress over-arching site theme. The SLP themes allow users to tweak the CSS that renders the search form, map, and results of location searches to create in-page layouts that better fit within their WordPress theme layout.
Until this past release it was a very tedious process to update themes or create a new theme. In the latest release there are some 30-odd SLP theme files. The problem is that when I find an over-arching CSS issue, like the update to Google Maps images that rendered incorrectly on virtually EVERY WordPress Theme in existence, it was a HUGE PAIN. I was literally editing 30 files and hoping my cut-and-paste job went well. Yes, I could have done CSS include statements but that slows things down by making multiple server requests to fetch each included CSS file. Since the store locator is the most-visited page on many retail sites performance cannot be a secondary consideration. Sass deals with that issue for me and brings some other benefits with it.
There are PLENTY of articles that describe how to install Sass, so I am not going to get into those details here. On CentOS it was a simple matter of doing a yum install of ruby and ruby gems and a few other things that are required for Sass to operate. Google can help you here.
My Sass Lives Here…
For my current Sass setup I am letting NetBeans take care of the pre-compiling for me. It has a quick setup that, once you have Sass and related ruby gems installed, will automatically regenerate the production css files for you whenever you edit a mixin, include, or base SCSS file.
I combine this with the fact that the assets directory is ignored by the WP Dev Kit publication and build tasks to create a simple production environment for my CSS files. I store my SCSS files in the ./assets/stylesheets directory for my plugin. I put any includes or mixin files in a ./assets/stylesheets/include subdirectory. I configure NetBeans to process any SCSS changes and write out the production CSS files to the plugin /css directory.
The first thing I did was copy over a few of my .css files to the new stylesheets directory and changed the extension to .scss as I prepared to start building my Sass rules.
I then ripped out the repeated “image fix” rules that existed in EVERY .css file and created a new ./stylesheets/include/_map_fix.scss file. This _map_fix file would now become part of EVERY css file that goes into production by adding the line @include ‘include/_map_fix” at the top of the SLP theme .scss files. Why is this better? In the past, when Google has made changes or WordPress has made changes, I had to edit 30+ files. Now I can edit one file if a map image rule is changing that has to be propagated to all of the css files. However, unlike standard CSS includes Sass will preprocess the includes and create a SINGLE CSS file. That means the production server makes ONE file request instead of two. It is faster.
As I reiterated this process I ended up with a half-dozen CSS rules that appear in MOST of my CSS files. Since all of the rules do not appear in all of my plugin theme files I ended up with a half-dozen separate _this_or_that scss files that could be included in a mix-and-match style to get the right rule set for each theme. I also created a new _slp_defaults include file that does nothing more than include all of those half-dozen rules. Nearly half of the current CSS files use all of rules that were “boiled out of” the CSS files.
Along the way I learned about mixins. At first I was a bit confused as to the difference between include files and mixins. Both are “pulled in” using similar commands in SCSS, @import for the “include files” and @include for the mixins, but what was the difference? While you can likely get away with “faking it” and having mixins act like includes they serve different purposes. I like to think of a mixin as a “short snippet of a CSS rule”.
A common example is a “set the border style mixin”. In the simplest form it can set the border style with a rule for each of the browser variants. This rule is not a complete CSS rule but rather a portion of a CSS rule that may do other styling AND set a border. The mixin includes the -moz and other special rule sets to accomodate each browser. Rather than clutter up a CSS entry with a bunch of border-radius settings, use a mixin and get something like:
That is a very simplistic way of using a mixin. One advantage is that if you decide to change the default border radius settings in all of your CSS files you can edit a single mixin file. However that is not a typical use. Yes, you can create subsets of CSS rules, but it really gets better when you add parameters.
At a higher level a mixin is more than just a “CSS rule snippet”. It becomes more like a custom PHP function. In typical coder fashion, I snarfed this box-shadow mixin somewhere along the way:
Notice how I now call in the include with parameters. This is passed to the mixin and the Sass preprocessor calculates the final rules to put in the CSS file. This makes the mixin very flexible. I can create all sorts of different box shadow rules in my CSS files and have the cross-browser CSS generated for me. No more editing a dozen box shadow entries every time I want to change a shadow offset.
Here is what comes out in the final production CSS when using the above mixin. You can see where the parameters are dropped into the .results_entry CSS rule:
This is only a start of my journey with Sass and I’ve barely scratched the surface. However I can already see the benefits that are going to come from using Sass. In fact I already used it to fix a problem with cascading menus where one of the SLP theme files did not contain a rule set. Rather than copy-paste from another theme file that contained the proper rules I only needed to add @import ‘include/_slp_tagalong_defaults’ and the problem was fixed.
Going forward Sass will not only increase my throughput in CSS development but also improve the quality of the final product that reaches the customer.
My first SLP Theme file, Twenty Fourteen 01, that was built using these new Sass files is only a 136 line CSS file with LOTS of whitespace and comments. When the final processing is finished it has all of the rules necessary to support the current add-on packs and style them nicely for the WordPress Twenty Fourteen theme in all major browsers.
Some of the customer sites will require fairly extensive CSS and page layout tweaks. Making those awesome looking sites doesn’t come easy and usually isn’t rolled up in an exactly-perfect-just-right WordPress + Store Locator Plus theme. Luckily the Store Locator Plus add-on packs make it very easy to tweak the plugin layout controls which gives your web graphics design team all the tools they need to get it “just right”. No code editing or inline hacks required.
Here is the summary of what you will need to get the job done:
If you want full layout control of the advanced themes you will need to get at least the Pro Pack.
A few weeks ago I was on my Google Drive and organizing stuff from several project, prospective business ventures, and my WordPress plugins. I have a half-dozen “things” going on these days and need to keep my notes, spreadsheets, flow diagrams, and other materials organized. I created folders and moved stuff around. To make it even easier to find things I assigned a color code to each folder as visual clues make for faster navigation once you train yourself on things like colors and shapes. This is why good icon design is paramount, given mobile desktop UX that proliferates our lives thees days.
However, at Google Drive I noticed that the colors I assigned to various project folders only shows up as a colored box on the drop down menus as well as a few other discrete places. I decided to drop Google a note via the web feedback form. “Hey Google. Why don’t you color code the FOLDERS themselves instead of keeping them all gray? Should be easy enough to do. You obviously are passing color code data to the UX already.”. Something to that effect.
I never got a response, but today when I went to my Google Drive I saw EXACTLY what I had requested as part of the updated UX.
Unfortunately Google never responded to my suggestion other than their typical bot responder. Did they look at my suggestion and send it to a developer that said “Great idea, that will take 2-seconds to put in place” and baked it into the experience? Or did they already have this planned for months? Approved by committee and a band of meetings to to a UX review analysis and full UX studies? I’d like to think Google is still able to operate in an Agile fashion, fast & nimble and responding to input quickly. Or have they become a typical corporate giant where it takes a year to get even a single pixel moved after design, analysis, re-design, and several board meetings before anything happens?
I’m not sure if my request and the 3-weeks to seeing it go live was just a coincidence. Probably. But I’ll fool myself into thinking that maybe I was the 10th request they got this month for that feature and some dev just “threw it in there”. If only Google would communicate with the user base, or even just the paid business apps accounts (yeah, I pay for gMail… I know, right?), and give us some clue that someone is listening. Whenever I communicate with Google I hear the “on hold music” playing in my head.. “Is anybody out there? Just nod if you can hear me…” – Pink Floyd.
Regardless, I’m happy that my Google Drive is no longer color blind. Thank you Google!