This is sort of a strange question, I think. I’ve been working on my portfolio (again), and noticing that some of my links go to documents that are on the website, some go to my medium blog, and some go somewhere else entirely.
Is there any recommended way to differentiate between these things? Either in terms of UX or in terms of specific UI patterns?
I know people often say that buttons are only used for things that change the data on the backend of your site (eg: the ‘create topic’ button below this field), and not for anything that just brings you elsewhere.
Does opening a document count as ‘bringing you elsewhere’?
I feel like it’s rude to not let users know if a click is going to open a document or open a link elsewhere.
You might enjoy Marcy Sutton’s talk on Button vs. Link usability and accessibility. While there are some standard usability reasons to have buttons change data and links used for navigation, there are accessibility concerns with using buttons for navigation that Marcy does a great job of explaining.
However, it’s worth considering whether or not implementing any sort of activity other than a straight-up link is worth implementing. The majority of web users today know how to quickly and easily open links in new tabs or windows, and would prefer to do so on their own accord. As far back as 1999, NNgroup has been recommending against forcing new windows/tabs. Some of the arguments that were valid then no longer hold water, but the general objection that forcing new windows/tabs breaks expected functionality and is hostile to the user remains. It’s worth noting that some users hate this functionality so much that there are browser plugins made to actively remove the a tag’s “_blank” attribute, which is responsible for opening links in new tabs/windows.
For all these reasons, I generally recommend against using using any a tag target attributes in your site to open new windows and tabs. There are too many usability and security objections to justify their use except under very specific circumstances, all of which you’re extremely unlikely to run into on a portfolio site.
Take a portfolio build on progressive web app framework (or even quasi PWA) - if you then link your pdf-based resume (Is it not very common?) without target attribute you’re breaking the flow of your site/application (history.back action would require reloading whole framework vs using already stored variables) and in a sense you’re giving up control over tab/window. If you ask me it makes perfect sense, assuming it is somehow indicated to the user, to use new tab/window when link action involves using a plugin to view document / downloading a resource or simply takes you out of an application.
PDFs are an entirely different conversation. Since you’re using it as the basis for your argument, let’s talk about them, and why there’s zero reason for a UXer to rely on a PDF on a portfolio site, especially as a resume.
###PDFs Lack Responsive Design
A majority of today’s web traffic is done on mobile devices. PDF design is static, and attempting to view a PDF document on a mobile device can still be a frustrating experience, especially for those using out-of-date browsers or devices. From a responsive design perspective, PDFs are about the worst-possible solution to a problem.
###Default opening behavior for PDFs is browser-dependent
Some browsers will attempt to use a built-in PDF viewer. Others will attempt to open the document in whatever program is set as the default PDF viewer. Mobile, PC, iOS all affect how the browser attempts to handle PDFs. With a myriad of different solutions, there can be no expected behavior-- and no truly right away to code a link to such.
###PDFs have a host of security concerns
PDFs have played host to a bevvy of security concerns over the course of the years. I won’t go into details here, but suffice it to say that including a PDF on your site increases security considerations… considerably.
###There are many way better options than using a PDF for a resume
LinkedIn, in particular, comes to mind. There are also a host of different HTML/WordPress/Joomla/Etc. templates out there built specifically for resumes, all of which support responsive design and eliminate security concerns associated with target="_blank" and PDF files.
There’s no need to do things the hard way.
While we’re talking…
Sure, that will work, in some circumstances, but it’s far from foolproof. If you have concerns for supporting legacy browsers, for instance, it’d be a poor choice of defense. Also, notably, Edge does not support noopener.
Quite apart from that, it’s a hack that doesn’t address the main difficulty with opening links in new tabs or windows in the first place. Forcing new windows/tabs breaks expected functionality and is hostile to the user.
Oh no, I’ve used PDF case just as an example of possible interruption to your portfolio app (I will take a mind shortcut and call portfolio framework on quasi/progressive web app - a portfolio app), no way am I attached to this one - lunching LinkedIn in same tab/window will terminate your portfolio app the same way lunching a pdf file would. I assume egoistic gene approach here (the same approach mentioned LinkedIn, Facebook or even this forum took) when building an app and by this standard disruption of an app continuity would be way more expectation breaking then forcing a new tab.
On the side note - interestingly I’m getting huge chunk of my portfolio traffic from LinkedIn profile not the other way around. Also I’ve decided to include .pdf resume just recently after being asked for one by recruiters one too many times. In my part of the world they still prefer collecting portable documents after reviewing portfolio (sort of trophy I guess).
While this is true for the most of the web - I think it is logical to assume recruiters and clients are still preferring to use desktops as they work tools. Again this may be evident just in my part of the world:
OK, looks like the answer to my question is not a simple one! (which might be why I couldn’t figure it out!)
In my case, yes, my documents are PDF format. They include my resume, but they also include design artifacts of various sorts, including reports, summary documents, and similar things.
I’ve had a lot of recruiters and similar request PDF format for my resume. Perhaps it’s best to offer a link to a resume page - not a PDF - and within that page offer the option to download a PDF version?
For the design artifacts, I’m not sure what makes the most sense! They are largely - but not only - text-based, and could likely be translated into a web page.
I’ll take a closer look at the links that @dougcollins sent, as I’m definitely interested in keeping my site accessible.
I do also have links which go outside of my portfolio page: most of these are to my medium blog (for more details and more personality included) and some are to the issue tracker for an open source project I’ve worked on.
If a recruiter or a hiring manager asks for your resume in PDF there is nothing wrong with sending them a PDF. They should be set up to read it.
There’s also nothing wrong with having your resume as a page on your portfolio site. It is, after all, just text (for the standard definition of “resume.”)
