I have a small application that will be used by both spanish and english users. The application has about four webpages with various asp.net functions. The database backend is sound.
What is the best approach for the front end / UI? Two websites with the different languages ? A single website with all text in both EN, ES? Or a single website with text appearing in the language of their choosing?
EDIT: This is an ASP.NET application
Two websites with different languages is a lot of maintenance. Any modifications made will need to be done twice. For this reason, as a programmer, I dislike it. However, if the person maintaining the site prefers it this way, then by all means, go this route.
However, if you are looking to provide a proper bilingual solution, you would definitely be better off with a single website instance, with a multilingual data provider.
There is a pretty good one for Wordpress that I have been playing with lately, called LangSwitcher. I have no idea how you have your website setup, or what you are using to develop it. Just throwing out an idea for you.
I'm unsure how to do it specifically in .NET, but a solution is to store the text in a database, and select which language as the page is generated (ideally by either URL (like /en) or cookie setting). Any resources can be stored in "en" and "es" folders, which should use the same logic to select. Then, as long as you're consistent, your translators / graphics people can just look at the raw, un-translated files, translate, put in the proper folder / database location, and viola.
Any number of languages can be handled, easily extending in the future, and it can even handle most language-specific layouts if you do the same with your CSS files. You should be using CSS to do all layout / styling anyway, in part for reasons just like this.
No matter what, you need more than one of every kind of language-specific data, so you're best off using as much text as possible so your graphics people don't have to pull double-duty in addition to the translators. Using CSS to put the text over the image lets you use a single image for any number of languages, and you can do some pretty impressive stuff with just CSS styling of text. If you want to get tricky, and don't mind breaking the site for older browsers, consider rendering things with the <canvas>. Just pull in the language-specific text & definition with Javascript.
In the meantime, there are a bunch of website widgets to do automatic translation, though they obviously don't touch images (another reason to stick with text wherever possible: anyone using a translation tool will be able to read it). I'm personally a fan of Google's: http://translate.google.com/translate_tools
None are perfect, but it's better than nothing.
Related
Many big website (google.com, apple.com, microsoft.com) are never validated. When the big shots don't do it, is there a reason why others should?
w3.org provide a page dedicated to people asking just that question, it's here.
Of course places like Google and Microsoft are there to appeal and should all be consistent across browsers. The w3 does have some good points
Using standard, interoperable markup and stylesheets, on the other hand, offers a much greater chance of having one's page handled consistently across platforms and user-agents. Indeed, most developers creating rich Web applications know that reliable scripting needs the document to be parsed by User-Agents without any unexpected error, and will make sure that their markup and CSS is validated before creating a rich interactive layer.
When surveyed, a large majority of Web professionals will state that validation errors is the first thing they will check whenever they run into a Web styling or scripting bug.
Another very important point is maintenance. A strictly valid XHTML document as much easier to maintain than a bowl full of HTML tag soup. Trust me.
We must remember that the markup is there as a data format. The way a browser renders this markup is what's generally important to a user.
Do remember: household-name companies expect people to visit because of the name and in spite of dreadful websites. Can you afford that luxury?
They are probably validated, but need to support older browsers (like IE6), so comptability-code is added.
Just because someone else doesn't, doesn't mean it's not a good thing. When you validate, you not only find out if your pages are well-formed, but you also track down bugs in your code, make the web pages easier to maintain and your code is more likely to work cross browser as well with future browsers. In addition to this, it shows that you take your job serious and that you have a good habit of trying to generate quality code.
Staying strictly within a known range of syntax (or technologies, in general) is good for optimizing maintenance costs, because all technologies you depend on (browsers in this case) are very well tested for the standard-conforming cases (subset of HTML/CSS/JS) only and are only randomly tested beyond.
I am developing a multilingual web application that has a nice looking UI. I thought using CSS 3's font-face property to make it even nicer UI, but I'm not really sure if that's a good idea. According to some people I have talked to, different languages need different fonts. This means that there is no single font that can display characters of all languages, because the same character may look different across languages.
For example, according to Wikipedia, the Unicode code point U+4EE4 looks different in Korean and Japanese languages.
So my question is, would it make most sense to contain the fonts within the language packs -- or within the themes of my UI?
If you're going multi-language, use the lang or xml:lang attributes to properly call out the language of a text snippet or the page to the browser and let the browser decide the proper font. This should work much more reliable than trying to do this from CSS.
I am looking for someway to do Flash type movies but with AJAX instead? Flash requires plugins, SEO is difficult and my experience is people tend to stay away from Flash websites unless they are really really good.
Can any provide some insight?
Maybe something like this:
http://activeden.net/item/handdrawn-deeplinking-urban-website/full_screen_preview/40657
You could try and play with the HTML5 canvas tag...
http://flash.digitalmedianet.com/articles/viewarticle.jsp?id=876219
You could use dynamic refreshing of SVG using Javascript, but you will have your work cut out for you.
Javascript, and lots of it, is one option.
Also, sliverlight 3's new navigation model supports deeplinking for SEO, and is really quite powerful for animations
try some of these
http://sixrevisions.com/javascript/10-impressive-javascript-animation-frameworks/
http://hacks.mozilla.org/2009/06/rendering-svg-canvas-burst/
http://raphaeljs.com/
I've been thinking of the same thing, going with javascript rather than flash on some stuff. This works great for small components inside a html website. But to do a whole js site, I'd strongly recommend AGAINST that.
From my experience, the same animation in flash vs javascript... JS is more processor intensive. I don't want to comment on as to which magnitude, but it's noticeable.
Bats also have a funny way of dealing with javascript and ajax content, so don't expect the same result in terms of SEO just because you're not using flash. But because people have used javascript to do content injection/replacement crawlers might be better at searching through the info. There are other ways of dealing with Flash SEO issues. (Gaia framework is not a bad starting point)
Another advantage of not using Flash or Silverlight is that most mobile devices ignore this stuff. However if you're planing on creating a site that acts like flash, the usability across these devices will likely not be consistent.
If you do decide to go this route, it's going to be much like going into a jungle and hacking your way through. Whereas with flash you're likely to be going through a well marked and paved landscape. You can get to the end result either way, but consider how much effort it will take. Flash has internal and community libraries that do all kinds of stuff, with js you'll be writing a lot of your own code and will have beta libraries that might not work well across all browsers.
But on the upside, you'll be a pioneer :)
I'm a software developer, and I'm going onto a project now that involves implementing a website using ASP.NET (3.5 / 2008, using the Web Client Software Factory). I've been tasked at creating a UI / UX Design Document for the project, however I don't really know where to start.
I've been on one project in 3 years where there was a formal UI design document, which included layout and style guidelines/rules (e.g. the application has a header, navigation, etc., links must be colour A, buttons for positive actions must be on the right, etc. etc.). It was pretty useful in hindsight, I appreciated that someone went into that much effort too - even defining the CSS classes in the document. However, the doc was based on an existing application and conformed to the business' overall corporate identity.
The current project is a new project, which at the moment doesn't have clearly defined requirements (yes, I know... how do you design when there aren't many requirements... I digress). It is hard to know what functionality exactly will be needed. There are two different user types / personas, but no formal research will be performed on them for this document. Also, I'm not sure of the corporate identity, apart from that the business has some rules regarding use of their logo, which I'll only get further clarification on in a few days time.
So I'm slightly in the dark, throwing paint at a canvas, hoping I get a pretty picture at the end (if only I were Jackson Pollock).
What would you include in this document? It is aimed at the business (the client), as well as the developers. I can think of only the below:
Layout - header, footer, content, navigation
Styles - colour palette and styles of the different expected components
User Interactions - when a user performs an action and must wait they are notified by a modal dialog, validation is done using AJAX, navigation should be contextual, tasks should be performed with a minimum amount of clicking / navigation, etc. etc.
Has anyone got any experience in creating such a document, or any known, tried and tested process for UI design?
Thanks,
James
There' all sorts of elements that could be included in such a set of documentation:
visual style guidelines (colors, typefaces, sizes, icons, etc)
branding guidelines (corporate logos, colors, messaging, etc.)
copyrighting style guide (terminology, proper messaging, proper voice, etc.)
persona/demographic targetting
page layout guidelines
CSS guidelines/standards
JS guidelines/standards
use cases
accessibility issues
usability issues
example implementations
IA path flows
Wireframe components
etc.
I'd pick up this book if you can to give you a start on thinking about this:
http://www.amazon.com/Web-Anatomy-Interaction-Frameworks-ebook/dp/B002ZY5FCW/ref=sr_1_2?ie=UTF8&s=books&qid=1262983955&sr=8-2
Along with all the other obvious components of your planning document, it would be a good idea to sketch portions of the UI along with an accompanying narrative of the specific use cases illustrated.
I've had issues in the past when attempting to communicate UI ideas. It is often useful to make sketches of dialog boxes and sequences of actions. If those sketches look too "real", then there is a tendency for them to become the spec for the final product.
To mitigate this, I've been playing with Balsamiq Mockups. It has the nice property that it is an editable back of a napkin, and deliberately renders all objects and screen layouts with a hand-drawn feel. I like the results I've achieved with it for small, internal projects. I haven't (yet) had the chance to use it for a large project with many external stakeholders.
The Wikipedia article for Human Interface Guidlines has some great links that I was going to suggest. Some of them may have far more information than you require, but they should give you a good idea as to what types of things you should add.
I have always found Apple's guidelines very complete and useful, but they are definitely very complete and require a lot of reading.
UX documentation is a critical part of the UX design procedure. It functions as a connection, providing context to the product’s lifespan from the initial concept to the present iteration.
Good UX documentation is straightforward yet lean. It should be favorably attentive, actionable, and purposeful. UX documentation is a functional document of a product’s journey from the beginning to the current release. This documentation is important for several reasons:
Organizational memory
Onboarding & handovers
Single source of truth
Fosters better communication & collaboration
A valuable R&D and IP
I've done plenty of programming before for CLI and the web, however recently I am getting into desktop GUI programming.
Most of the tutorials for GUI programming I found just explain the different controls you can use and leave it at that. Some of the better ones also skim over a few usability issues.
However, my problem is not with the APIs, or the theory but with my code.
How are you supposed to organise different views your application might have (e.g. a IM application has a login view, a contacts list view, a conversation view etc.).
Are these supposed to be different classes or different methods on one class?
Different panels that are hidden and revealed, or different windows altogether?
I'm hoping for answers as language agnostic as possible, but in case that's not possible, the languages/frameworks I am considering are Java/Swing or C#/WPF. However, if there's another language/framework that is significantly better for learning from, I would consider using that.
Normally each view will be a seperate class in a seperate file. The class will then most likely implement some base class like Window or Control.
As far as organization, if it's a simple app, put them in the root or in a UI folder. Or perhaps a Window folder and Controls folder.
If it's a large app with several views, than break them out into functionality, i.e. an IM folder.
I would say go with what Joshua said and as far as using different panels that are hidden and revealed, i've worked on old code and it's a nightmare to re-use (8000+ lines of Delphi 6!) so stick with different windows as much as possible!
The generally recommended overall structure of the program is the model-view-controller (MVC) type of structure. So, first off, don't make the actual data part of the views, it goes into the model. From here, since the only data in each view window is now almost entirely just layout information and what to do on an action (click, data display, etc), if these are different, they should probably be different classes. If there's some general functionality that can be factored out, you can make this a base class and inherit from it, but in the end, windows with different functionalities should be different classes.
If you are going to be using one of the mainstream IDEs it will handle some of this work for you. The default will be a different class for each form. Hidden panels and tabbed interfaces are nice features but do yourself a favor and learn the ins and outs of embedding groups of controls into form. Some frameworks allow you to directly embed one form into another. Others have special containers that can be be embedded.
The point of these is to break up your functionality so you don't wind up with a bloated form class that's difficult to wade through.
I would also spend some time looking at some of the architectural patterns for keeping your business logic separate from your UI. Check out this link for a good starting point.