I run an online literary journal which leads to an indexing problem--our content is not "about" literature -- it is literature. As such, Google is really bad at identifying what's going on, and due to the very low keyword density we have to try and work with, I've been looking for ways to slash interface text and turn it into iconography where possible.
I've been looking for a way to do the same with our post dates, but it's been a long search. I stumbled across the idea of using CSS generated content content:attr(id) to substitute the ID attribute of an invisible image into the page itself.
This works on the display level, however, I haven't been able to track down anything conclusive on whether this interface-only text will still get indexed, or whether we'll be able to move away from months and days of the week being our most-frequent keywords. I know Google will still see it; anyone know if it'll "count"?
As far as I'm aware, the 'best' way to ensure something is hidden from a search engine is to either load it via AJAX or (shudder) include it with flash.
If you feel that the non-content aspects of your site are adversely affecting your site's standing in the various search engines, you could load these elements via AJAX.
Only if you really think these elements are seriously affecting your position.
Below is an image describing areas of this page that one could conceivably post-load via AJAX, if one was overly concerned about their impact on SEO:
I know this doesn't specifically answer your question, it's a suggestion for an alternative way to tackle your issue.
Related
My department has analytic rule conditions in DTM that trigger events based on particular classes or custom data attributes. I'm concerned that if our dev team makes a change that would break the rule, we wouldn't find out until it's discovered that the metric is no longer tracking.
We're trying to future proof our scripts to allow for changing conditions (eg: using regex for changing class names &/or functions to traverse the DOM to find a condition without it needing to be hardcoded), but I thought someone here might have experience with this type of issue. How was it handled at your company?
**EDIT:**I'm exploring using custom Data Elements within DTM that are created with javascript that has multiple conditions for traversing the DOM in ways we've identified. So a sort of data layer that's controllable by my team.
Note: This isn't really an actual coding question; more of [analytics/marketing tag] coding principles/best practices. So I'm not entirely sure this question belongs on SO (maybe one of the other stack exchange sites, perhaps superuser.com?). But I'll answer here anyways.
TL;DR - You need to get site devs involved and have them take on some level of initial and ongoing ownership of it.
Tag managers sell themselves on being able to deploy tags without getting site devs involved, and many times this works out in the short term. But in my experience, this kind of passive deployment just doesn't work out in the long term, especially for websites that have active and regular changes over time.
In my experience, the only way to effectively help prevent site devs from inadvertently breaking the tracking from this, is to include the site devs in the deployment and make them take ownership of it on some level, so that it is something they are aware of within their own system/flow.
Sometimes it is as easy as having designated classes or attributes added to html tags on the page. For example, you can write a spec for the site devs to add a data-analytics='true' to any header, footer, CTA links on a given page, and tell the site devs this is something they need to keep as part of their workflow whenever they make changes to the site.
For more complicated things, you could spec for them to do something like broadcast a custom event for you to listen for. For example, maybe you have a purchase confirmation page and right now you have code in DTM to trigger based off the URL, or scrape the page for details about the purchase to push to tags. Instead, create a spec with instructions for the devs to put that in a data layer object and push to a custom event, and then create an event based rule for it.
The overall theme here is to create a spec document for all the things you want to be able to track on the website, that you know you can't reliably passively track without it breaking sooner or later, and hand the document to the devs and tell them they need to make it a part of their flow when making changes to the site. Bonus points if you can get them to loop you in whenever changes are going to be made and pushed to production, that you may go to your dev/qa version of your site to test to make sure your tracking still looks good.
The overall overall theme here is in order to prevent site devs from breaking your tracking, you need to be more proactive about making them and keeping them aware of your tracking, and in practice, this usually means putting some of the code work on their plate to own, so it's something in their history, in front of their face to see and know about. Because it is a lot easier for a dev to take notice of a data-analytics='true' in the header nav links they are about to restructure, than knowing hey, some piece of code in DTM relies on this current structure.. something that's not more directly in front of their face in their own code editor/environment.
Yes, actually accomplishing the above is often easier said than done. But it is the reality of the situation. Passively tracking things in a tag manager rarely works out for longer term stuff, short of "every page" tags that have little or no customization requirements at all.
I tell you from my own experience of over 10 years of working in the digital marketing and analytics industry, specifically with implementation, I have seen this time and time again. Too many times to count. Clients often want to and actually take the easier route of leaving the site devs out of the loop, all tracking requirements done solely through whatever the tag manager is capable of doing.
I've seen setups with hundreds of rules with trigger conditions based off scraping the page for some id or class, or some complex css selector dependent on 5 levels of html structure not changing. Or some random cookie you just assume means what you think it means. And you're spending more and more of your time playing whack-a-mole trying to re-adjust/fix individual rules/selectors as the next random change happens, and then one day comes a full site redesign and it's a nuclear bomb on all your tracking efforts.
And time and time again, without fail, eventually they wind up asking exactly what you've asked here, kicking themselves in the arse for the time and money they spent already on it for that "quick win", because nobody is confident in the data and they're wondering why they are allocating money/resources on tracking if it's just a bunch of trash, broken, pothole data. And the solution to it has always been "site dev awareness".
If it helps.. one card I sometimes play if I have a hard time convincing the dev team or other powers-that-be to jump on that bandwagon, is to point out that one of the biggest reasons for tracking websites is to help companies determine whether or not it's worth investing money in said website. If they can't determine that, then they may not be so inclined to do so, which means their need to even have a site dev team may also decline. To be more candid: it is something that helps justify their job.
What is the benefit of writing meaningful css .class and #id names? Do screen readers speak to help the user understand the meaning and purpose of content inside the tags?
Generally-speaking, it's beneficial for the developer/designer only.
Again, as all your recent questions on semantics, the answer stays the same:
It all depends on the data-context of the entity in question.
If your element holds a meaningful field, it is useful to assign it a class (even if you do not want to apply CSS to it) just to easily define that particular field:
<span class="username">Andrew Moore</span>
Doing so has the following advantages:
It easily identifies the field's content in your code.
It increases maintainability.
It helps parsers and third-party applications to fetch this field's value.
Microformats are just a larger example of this. Simply put, they are a set of pre-defined elements and attributes that hold a particular set of data, meant to ease parsing by third-party tools.
Other answers are good, but I will focus on the scraping/third party tools aspect here.
Case 1 is spiders and crawling like search engines. If they parse your page and see something like id="username", they will be more likely to figure out some meaning in that than id="div-style-32". Granted, I'm not sure Google is doing this sort of thing now, but it could be if more people were better about it.
Case 2 is people writing scripts to pull down the HTML and process it in order to extract its content as data. Pretty much anyone who wants to do this can with any markup, its just a matter of how annoying it is. Cleaner and more well described markup allows the scraper script to more easily find the information it needs due to it's increased semantics.
This also includes things like browser extensions or Greasemonkey scripts that allow users to alter the behavior of the site. It will be easier to create these modifications with cleaner markup.
But if you don't want people scraping or modifying your site with client side extension, there is little you can do about from a technical standpoint. You can't stop it, you can only make it more of a pain in the ass. And the benefits of maintainability for the site developers are huge. So really, why not?
In short it makes all the different things you or others could do with your site easier to do.
You don't do it for the machines but for the humans.
If we only cared about machines we'd still be coding in assembly :)
I'm implementing "news" section in asp.net website. There is a list of short versions of articles on one page and when you click one of the links it redirects you to a page with a full article. The problem is that the article's text on the second page will come from database but the articles may vary - some may have links, some may have an image or a set of images, may be differently formatted etc. The obvious solution that my friend have come up with is to keep the article in the database as html including all links, images, formatting, etc. Then it would be simply displayed on the second page. I feel this is not a good solution as if, for example, we decide to change the css class of some div inside this html (let's say it is used in all articles), we will have to find it and change in every single record of the articles table in our database. But on the other hand we have no idea how to do it differently. My question is: how do you usually handle something like this?
I personally don't like the idea of storing full html in the database. Here's an attempt at solving the problem.
Don't go for a potentially infinite number of layouts. Yes all articles may be different but if you stick to a few good layouts then you're going to save yourself a lot of hassle. These layouts can be stored as templates e.g ArticleWithImagesAtTheBottom, ArticleWithImagesOnLeft etc
This way, your headache is less as you can easily change the templates. I guess you could also argue then that the site has some consistency in layout.
Then for storage you have at least 2 options:
Use the model-per-view approach and have eg ArticleWithImagesAtTheBottomModel which would have properties like 1stparagraph, 2ndparagraph, MainImage, ExtraImages
Parse the article according to the template you want to use. e.g look for a paragraph break if you need to.
Always keep the images separate and reference them in another column/table in the db. That gives you most freedom.
By the way, option #2 would be slower as you'd have to parse on the fly each time. I like the model-per-view approach.
Essentially I guess I'm trying to say beware of making things to complicated. An infinite number of layout means an infinite number of potential problems. You can always add more templates as you go if you really want to expand, but you're probably best off starting with say 3 or 4 layouts.
EDITED FROM THIS POINT:
Actually, thinking about it this may not be the best solution. It could work depending on your needs, but I was wondering how the big sites do it. If you really need that much flexibility, you could (as I think was sort of suggested) use a custom markup. Maybe even a simplified or full wiki markup. I'd still tend toward using templates in general, but if you need to insert at least links and images then you can parse for those.
Surely the point of storing HTML with logically placed < div >s is that you DON'T have to go through every bit of HTML you store to make changes to styles?
I presume you're not using inline styles in your stored HTML, and are referencing an external CSS file, right?
The objection you raise to your colleague's proposal does not say anything about the use of a DB. A DB as opposed to what: files? Then it's all the same. You want to screw around with the HTML, you have to do it on "every single record." Which is not any harder than "on every single file." Global changes are a bitch unless you plan for it by, say, referencing an external CSS. But if you're going to have millions of news articles, you had better plan on versioning the CSS as well.
Anyway, the CMSes do what you're thinking of doing. Using a DB is a fine way to go. How to use it would depend on knowing the problem more intimately.
Have you looked into using free content management systems? I can think of a few good ones:
Joomla
Drupal
WordPress
TONS of others... just do some googling.
Check out this Wiki article: http://en.wikipedia.org/wiki/List_of_content_management_systems
this is my firts post here ever.
I have to develop an aplication for a group of people with special needs. The functionality is really trivial, however, i have no clue of how to do the interface for them to be able to use it.
Their intelectual habilities are perfect, they are actually studying high school, but one of them types with his nose which needless to say, is very dificult and another one types reaaaaaaally slowly with only one of his fingers and neither can use the mouse.
I was wondering if i could use javascript to develop a usable interface, based on huge grids or something like that or maybe you guys have a better idea.
Political incorrectness aside, why don't you ask them? You're talking about accessibility here, if they're using computers they must be able to tell you about what they like or dislike about user interfaces that they've encountered.
I'm going to split my answer into two parts - design and implementation.
From a design perspective, it's important not to be intimidated by the fact that the users use a computer in a different manner. Treat this like any other project. Observe how they currently use other apps, and ask about the kind of things that they find helpful, or have difficulty with. If they claim nothing is difficult, ask a teacher or assistant, who will be familiar with the kind of things they struggle with.
Once you've started implementation, try an idea and get initial feedback. If you simply ask how they find the prototype, they'll likely say it's ok. Instead, try observing them using it without saying anything or giving guidance. If they get stuck, let them find their own solution to the problem. If appropriate, you could ask the user to speak their thoughts out loud (e.g. "I need to save this form, so I'm scrolling to the bottom, and clicking save").
On the development side, try to use web standards (valid HTML, CSS and Javascript). People often point to the "Web Content Accessibility Guidelines 2.0" (WCAG2) but this is quite turse and hard to understand; there are many more friendly articles on "Web Accessibility".
Someone with a physical disability is likely to use an alternate input device, such as a "Switch", onscreen keyboard, head-tracking device, a device for pushing keys on the keyboard, or speech recognition. Many of these methods involve simulating the keyboard, so by far the most important thing is to consider the accessibility of your site without using a mouse. For example, try tabbing through the page to see if you can access all elements in a reasonable amount of time. Consider using the acesskey attribute to provide an easy way to jump to different parts of the page (using 0 through 9 is often recommended so you don't interfere with browser shortcuts).
Also make sure that no part of your site is time-dependant, as different users may take different amounts of time to perform a task. For example, don't use the onchange Javascript event to update a page based on a listbox selection. Ensure you have alt text for images, so it's accessible for speech recognition. make the pages short enough so that excessive scrolling isn't required, but not so short as to require following lots of links.
Those are just some ideas to get your mind going in the right direction - but there are many accessibility resources on the internet - steal freely, and don't reinvent the wheel.
I realise I haven't addressed your question about Javascript - that's because I think it's probably one of the less important considerations. If possible, use Progressive Enhancement techniques to make the site work with and without Javascript. You might also look into the WAI-Aria standard for giving semantics to your Javascript.
And finally, to reiterate my initial point - make something simple, show it to the users, tweek, and show again.
It doesn't really matter what technology you use. Use whichever suites you.
But, make sure that you make UI components BIG in size(Bigger buttons, bigger font, bold font, coloured font(are there any colour blind?). This is for the ease of use of people (you said someone types with nose).
Also, better to have audio as informative source along with the usual screen display whenever some wrong action is performed on the application. This way visually impaired people will be assisted more.
Do it well, you are doing a divine job.
The first thing that you should read up on is the Web Content Accessibility Guidelines written up by the W3C.
In a nutshell this document describes the basic principles for people with disabilities in general.
For your needs regarding persons with special needs, you might want to look at Jakob Nielsen's article on Website Usability for Children, wherein principles of web design for young children or people with otherwise limited cognitive ability are outlined.
The sources I've read on making web pages accessible provide conflicting information on whether the 'title' attribute is actually useful. Some claim that it's best practice to give a web control a title attribute containing a more detailed explanation than the visible text on the control provides. Others claim that the default for most screen-readers is to ignore title attributes, so the attribute is useless in practice (except for providing tooltips for sighted readers). So, what do you folks recommend?
Not all screen readers ignore titles but some do. This is one of those areas though where it is best for you to include it as those who can get that content will. Plus search engines love title tags.
I'm actually encountering this problem with another Stack Overflow user right now in this question. Specifically, the reasons for a verbose title are:
A good title communicates to your visitors a lot of information about what the page is about
Google places higher weight on text within the title tag
However, this is lost on the user when they get to your page and have no idea what's going on just because you decided to game a search engine. Take Stack Overflow, for instance. A 50 word title may be good for Google, but how would you feel as a user if this question had the following title:
Should I make the Title Attribute Longer In Order To Acheive a Higher Ranking on Google, or Should I Make it shorter to make it accessible and not drive my Users Crazy?
In the end, while Google does matter; it doesn't matter more than keeping your user on your site once they are there; not to mention the benefit of a verbose title tag is lost on accessibility.
This website has a great article on the subject, and they write:
[...] The second reason has to do with SEO. Search engines need different information to rank the results of a particular query. Page title is one of the more important pieces of information they use to gauge how relevant your page is to a particular search term. This doesn’t mean you should load as many keywords as possible into the title — that defeats the first benefit — but you should ensure that each title succinctly describes the content of the page, including a couple of words you think people will search for. (Emphasis Added)
I use title on any links from my website as it is recommeneded by WC3 as per accessibility guideline 13.1 See http://www.w3.org/TR/WAI-WEBCONTENT-TECHS/#tech-meaningful-links
For a lot of these accessibility issues bear in mind that what is not used now by an application may be used in the future so it's best to err on the side of doing too much rather than the bare minimum.