Is it important to i18n your img alt attributes? - html

For those of you who i18n, do you i18n the alt attribute on your img tags? Is it really worth it?

Well, I guess if you wanted your site to be truly i18n'd, then yes.
It might be an extra headache, but some vision impaired people out there are thanking you :)
Also, are you using i18n JavaScript strings too?

If you decide to translate your alt tags and find yourself needing to manage and / or just get the actual translation done we have (what I like to think, obviously :) a pretty cool tool called String - http://mygengo.com/string
String is great for not just managing translations, where you can invite others to projects to help with translation, but you can order translations right in the service too. We've integrated our API into String to showcase our API and the ability to see status updates for numerous (100s...1000s) of jobs, translated by real people!
If you're interested in the API itself, we held a bounty contest not long ago with some fun winners for a number of platforms (Wordpress, Django, etc.): http://mygengo.com/services/api/lab/winners/
Just thought I'd share.

Related

Rules to pull reader-view like content from website?

I'm trying to implement my own little reader view app (an app that would do the same thing as reader-mode on safari), and there are a few things I find asking myself:
Is there a technical term for this feature (reader-view doesn't really cut it)?
Is there a standard that websites are supposed to follow in order to indicate the content they would like to have in their reader views
Is there an open-source set of HTML parsing rules to pull the "readable" content from a website?
Is the effort to implement such a thing simply too big for a single person in a few weeks and if so should I opt for services such as Instaparser?
I believe the original to be implemented by arc90, and they called it readability. You can check out their page here.
It's been ported to many different languages over time, so you could take a look at the different implementations to learn more about it, how it's done etc.
Python readability
JReadability
JavaScript
Ruby
This is just a small sample here, there's many more examples if you would like to find more.
Edit: Oops, after some more Googling I found this question with an answer that explains it very well.

When should I use HTML5 Microdata for SEO?

So I've been looking into this HTML 5 Microdata, but I'm not sure if or when it is appropriate to use. I know that if used with rating and you search a website it will pull up things like video rating and article ratings etc. But for Microdata like People or Places, is that so useful that I should start implementing it into all my websites - big and small? How big of an impact will this really have on my SEO if I start using Microdata on everything?
Maybe using something like http://schema.org/ as my standard term dictionary. I think that is what Google suggests using. Here's a link to the dev of microdata http://dev.w3.org/html5/md/ which will be helpful if you are unfamiliar with microdata
Following to that Schema.org - Why You're Behind if You're Not Using It... article on SEOMoz, I must say this question is not just about microdata and Google SERPs positions. I think it has to be taken in a much wider meaning:
Some advantages:
Implementing microdata on a website DOES increase CHANCE for Rich
Snippets displayed next to your site on Google search results. You can't say 'microdata = rich snippets', but you also can't say 'no microdata = no rich snippets' :)
Having rich snippets increases users' attention to that single search result and it CAN result in more clicks => visitors on your page.
Some cons:
Some rich snippets, which can be a result of using microdata, can let users find information they're looking for directly on the search results, without actually reaching your page. eg. if user is looking for a phone number and see it on rich snippet, he doesn't have to click and visit your page.
You have to decide on your own if you can take that risk. From my own experience (and that article comments as well), that risk is quite small and if you can, you should implement microdata. Of course, 'if you can' should really mean: 'if you can and it won't need the whole site to be rebuilt' :) If you have more serious things to do on your site, you should put them in front of a queue. Today, it's only 'nice-to-have', not 'must-have'.
And just for the end - I know my answer is not just yes or not the answer, but it's because the question is not that kind of question. However, I hope it could help you make your own decision.
My answer would be "Always."
It's the emerging standard for categorizing all forms of information on the web.
Raven Tools (no affiliation) has a schema.org microdata generator that's a good place to start:
http://schema-creator.org/product.php
They have a couple stock schema templates on that page (look on the left column).

Why should I use XFN in my HTML?

What is the benefit of using XFN (XHTML Friends Network)? I've seen this on multiple blogs and social networking sites but I don't really understand why it's useful. Other than being able to style these elements with CSS3 and select them with JavaScript, what's the benefit? Do you know of any sites out there that really utilize XFN to enhance the user experience? Also, are there similar alternatives to XFN?
Do you know of any sites out there
that really utilize XFN to enhance the
user experience?
Microformats aren't meaned to show extra information on the website itself, if it was, it could be used like John. You should think in another direction, for example, maybe browsers will support microformats one day.
Search engines may find this XFN-information interesting for one or another reason to see how the world is connected; I'm not sure what they actually could do with this information. You can read about that on Wikipedia
By the way, you can find out who your friends on the web are using Google's Social Graph API
Also, are there similar alternatives to XFN?
Take a look at microformat.org's wiki

Should I make it a priority to semantically mark up my pages? Or is the Semantic Web a good idea that will never really get off the ground?

The Semantic Web is an awesome idea. And there are a lot of really cool things that have been done using the semantic web concept. But after all this time I am beginning to wonder if it is all just a pipe dream in the end. If we will ever truly succeed in making a fully semantic web, and if we are not going to be able to utilize semantic web to provide our users a deeper experience on the web is it worth spending the time and extra effort to ensure FULLY semantic web pages are created by myself or my team?
I know that semantic pages usually just turn out better (more from attention to detail than anything I would think), so I am not questioning attempting semantic page design, what I am currently mulling over, is dropping the review and revision process of making a partially semantic page, fully semantic in hopes of some return in the future.
On a practical level, some aspects of the semantic web are taking off:
1) Semantic markup helps search engines identify key content and improves keyword results.
2) Online identity is a growing concern, and semantic markup in links like rel='me' help to disambiguate these things. Autodiscovery of social connections is definitely upcoming. (Twitter uses XFN markup for all of your information and your friends, for example)
3) Google (and possibly others) are starting to pay attention to microformats like hCard and hCalendar to gather greater information about people and events going on. This feature is still on the "very new" list, but these microformats are useful examples of the semantic web.
It may take some time for it all to get there, but there are definite possible benefits. I wouldn't put a huge amount of effort into it these days, but its definitely worth keeping in mind when you're developing a site.
Yahoo and Google have both announced support for RDFa annotations in your HTML content. Check out Yahoo SearchMonkey and Google Rich Snippets. If you care about SEO and driving traffic to your site, these are good ways to get better search engine coverage today.
Additionally, the Common Tag vocabulary is an RDFa vocabulary for annotating and organizing your content using semantic tags. Yahoo and Google will make use of these annotations, and existing publishing platforms such as Drupal 7 are investigating adopting the Common Tag format.
I would say no.
The reason I would say this is that the current return for creating a fully semantic web page right now is practically zero. You will have to spend extra time and effort, and there is very little to show for it now.
Effort is not like investing, however, so doing it now has no practical advantage. If the semantic web does start to show potential, then you can always revisit it and tap into that potential later.
It should be friendly to search engines, but going further is not going to provide good ROI.
Furthermore, what are you selling? A lot of the purpose behind being semantic beyond being indexable is easier 3rd party integration and data mining (creating those ontologies). Are these desirable traits for your data sets? If you are selling advertisement, making it easier for others to pull in your content is probably not going to be helpful.
It's all about where you want to spend your time.
You shouldn't do anything without a requirement. Otherwise, how do you know if you've succeeded? Do you have a requirement for being semantic? How much? How do you measure success? How do you measure return on investment?
Don't do anything just because of fads, unless keeping up with fads is a requirement.
Let me ask you a question - would you live in a house or buy a car that wasn't built according to a spec?
"So is this 4x4 lumber, upheld with a steel T-Beam?"
"Nope...we managed to rig the foundation on on PVC Piping...pretty cool, huh."

REALLY Simple Website--How Basic Can You Go?

Although I've done programming, I'm not a programmer. I've recently agreed to coordinate getting a Website up for a club. The resources are--me, who has done Web content maintenance (putting content into HTML and ColdFusion templates via a gatekeeper to the site itself; doing simple HTML and XML coding); a serious Web developer who does database programming, ColdFusion, etc., and talks way over the heads of the rest of us; two designers who use Dreamweaver; the guy who created the original (and now badly broken) site in Front Page and wants to use Expression Web; and assorted other club members who are even less technically inclined.
What we need up first is some text and graphics (a gorgeous design has been created in Dreamweaver), some links (including to existing PDF newsletters for download), and maybe hooking up an existing Blogspot blog. Later (or earlier if it's not hard), we may add mouseover menus to the links, a gallery, a calendar, a few Mapquest hotlinks, and so on.
My question--First, is there any real problem with sticking with HTML and jpegs for the initial site? Second, for the "later" part of the site development, what's the simplest we can go with? Third, are there costs in doing this the simple way that will make us regret it down the road? Also, is there a good site/resource where I can learn more about this from a newbie perspective?
­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­
If you don't require any dynamic content, heck, if you don't plan on editing the content more than once a week, I'd say stick to basic HTML.
Later, you'd probably want a basic, no-fuss and easily installable CMS. The brand really depends on the platform (most likely PHP/Rails/ASP), but most of them can be found by typing " CMS" into Google. Try prefixing it with "free" or "open source" if you want.
I'm pretty sure you can do all this for absolutely free. Most PHP and Ruby CMS's are free and web hosting is free/extremely cheap if you're not demanding.
And last/best tip: Find someone who has done this before, preferably more than once. He'll probably set you up so you never have to look at anything more complicated than a WYSIWYG editor.
Plain old HTML is fine, just as long as you don't use tags like blink and marquee.
I personally love tools like CityDesk.
And I'm not just plugging Joel. (There are others out there in this class I'm sure.) The point is they make making a static website very easy:
The structure is just a filesystem structure
pages have templates to consolidate formatting
all resources are contained in one file
easy and fast Preview and Publish functions
For a dynamic collaborative site, I would just install one of many open source CMSs available on shared hosting sites.
If you're familiar with html/javascript basics I'd look into a CMS - wordpress, drupal, joomla, nuke, etc. All of these are free. Very often your web hosting company will install one of these by default which takes all of the hard part out of your hands. Next is just learning to customize the system and there's tons of docs out there for any of those systems.
All that being said there is noting wrong with good old fashioned html.
In addition to some of the great content management systems already mentioned, consider cms made simple.
It makes it very easy to turn a static site into a content managed site (which sounds like exactly what you might need to do in the future), and the admin area is very easy to use. Our clients have found it much simpler to use than the likes of Joomla.
It's also free and open source.
Good luck!
There's no reason to not go with plain old HTML and JPGs if you don't know any server side scripting languages. Also, once you want to get more advanced, most cheap hosting services have tools that can be installed with one click, and provide things like blogs, photo galleries, bulletin boards (PHPBB), and even content management tools like Joomla.
I had the same problem myself, I was just looking for something really easy to smash together a website quickly. First I went with just plain old HTML, but then I realised a simple CMS would be better.
I went for Wordpress. Wordpress is mostly known as a blogging platform, but in my opinion it is really great as a deadly simple CMS as well.
why not simply use Google pages?
Here is an example of a website I did, takes about 2 hours, easy to maintain (not that I do (-: ) and FREE.
I think that suggesting you mess with HTML for what you need is crazy!
Plain HTML is great, gives you the most control. If you want to make updating a bit easier though, you could use SSI. Most servers have this enabled. It basically let's you attach one file to many pages.
For example, you could have your menu in navigation.html and every page would include this file. That way you wouldn't have to update this one file on every page each time you need to update.
<!--#include virtual="navigation.html" -->
I agree with the other commenters that a CMS might be useful to you, however as I see it, probably a solution like Webby might do it for you. It generates plain HTML pages based on Templates. Think about it as a "webpage preprocessor" which outputs plain HTML files. It has most of the advantages of using a server-based CMS, but without a lot of load on the server, and making it easy for you to change stuff on any of the templates you might use.
It's fine
Rails (or purchase / use a CMS)
Not unless you start becoming crazy-popular
It really depends on what you go with for 2. Rails has a plethora of tutorials on the net and any product you go with will have its own community etc.
To be perfectly honest though, if the dynamic part is someone elses blog and you move the gallery out into flikr you may find that you can actually live with large parts of it being static HTML for a very long time.
If a to Implement a website With User Profiles/Logins, Extensions, Gallery's etc s a Newbi then a CMS like Joomla, Etc are good , but Else if you presently have only Static Content then Its good to go with Good Old HTML, About JPEG , I though Presently Its better to use PNG or GIF as its Less Bulky.
Also About you Query About Shifting to Server Scripts , When you have Database Driven Material or When you have Other Things that Require Advanced Prog Languages , Just use PHP Scripts inside PHP , and Rename teh File as a PHP, Thats IT, No Loss to you HTML Data.....
Do Go Ahead and Launch you Site ......
Dude, you're talking about HTML, obviously you'll be styling your content with CSS. Wait till you run into IE issues and god forbid your client wants ie6 compatibility.
Go with the HTML for now, I'm sure you guys will hack it through. Our prayers are with you.
Personally, I'd never use JPEG images on a website, mainly because of three reasons:
JPEGs often contains artifacts.
Quality is often proportional
with filesize.
Does not support
alpha transparency.
That said, I'd recommend you to use PNGs for images since it's lossless and a 24-bit palette (meaning full colors + alpha transparency). The only quirk is that IE6 and below does not support native alpha for PNGs, however this could be resolved by running a javascript which would fix this issue.
As for designing a website, there's both pros and cons for this. I suggest you read through:
37 Signal's Why We Skip Photoshop
Jeff Croft's Why We Don't Skip Photoshop
As for newbie resources, I'd recommend you flip through the pages at W3 Schools.