I'm having some difficulty wrapping my head around building an OGC compliant Earth Observation ordering service. I'm not asking for a step by step process but rather hope to spawn a high level discussion about what might be the best way to approach this task.
There is this best practice document on what i would like to accomplish:
Order Services for Earth Observation Products OGC 06-141r2
However, i'm not sure whether i should get the schema(xsd) files that are at the bottom of the PDF and generate stubs from them, or leverage geoNetwork in some way. I have no idea where to start. Has anyone any experience implementing any OGC standards, best practices or something similar? Where do i start?
I would suggest contacting the editor directly. I believe that there are reference implementations that you can take a look at. The editor is Daniele Marchionni .
Cheers
Related
I am a UI/UX designer. Currently I got interviewed for a post and now they’ve given me an Exercise where I am supposed to do a complete UI review/Audit/Analysis of their product. I need some suggestions to do the exercise:
What medium do you think is best for presenting such a review? A video, An audio with visuals, or a document highlighting issues in UI with callouts?
What are the key points that need to be covered in such a review?
So that I submit the best exercise and get selected. Thanks in advance.
First of all you should know that UI/UX is not my area of expertise. But I've been directly or indirectly involved with it enough to know that it's not an exact science. People will often debate about what is the best for the user. Just remember that two users themselves might not agree on something.
So what I think is important is that you genuinely take the role of a user, try using the product imagining a scenario where you want to accomplish something. If you do it right, you should have some feedback on what works well and what could be improved. It's your opinion, the important part is that you can back them up with common sense or valid arguments.
As for the medium, I'd say that you should choose the one that communicates your views the best. I'd rather read through well organized text than go through a poor video. You'd probably want to impress, so whatever you choose, do it well! If the UX design was documented upfront, you would normally use that as the basis for your review. So look up UX design tools, you might be able to use one of them.
If you have time, a background in UML modeling might be helpful, particularly the ICONIX methodology, which encourages exploring different "what if" scenarios, rather than just desiging for the standard (most common) path. Also assuming that you've already looked up online resources describing common best practices.
Some libraries are very obvious to me. I mean I can create the math, string etc libraries on my own. I don't understand how people create API's like OpenGL, OpenCV, DirectX, and MFC. I don't understand how to write them on my own like I write libraries to compute math and string functions. Are there any resources on the net that would teach me how I can go about doing this.
Those kind of libraries are driven by two things.
1) is the domain that they're working in (notably GPU architecture, and their capabilities and limitations), and
2) the model of those capabilities as view by the API designer.
Simply, someone with some (ideally) reasonable understanding of the problem domain said "I think if you want to work with a GPU, I'd like the GPU to look like this", and came up with a model to present to the API consumer. Then the framework was written to convert that model view that the API designer contrived with the actual workings of the underlying mechanism (in this case a GPU).
Consider something like an Object Relational Mapper tool. Here, they're trying present an OO view mated to an underlying Relational representation.
The designers likely took some idea of what they wanted, tried them out to see how realistic it was do, and then started filling in the gaps and polishing the edges.
The way for you to start is to simply pick a domain which you have knowledge, but don't like how it works, and think "gosh, it would be better like this" and then start solving THAT problem. If things go well, you'll have some momentum and the process will likely get a bit more organic from there. But, ideally not too organic.
The hard part is putting your new API to work and USING it as someone who doesn't know the API, or necessarily the domain, would use it. Using it also gives you the opportunity to encounter the "gosh, it would be better like this" phase again.
Rinse and repeat until you're happy with the outcome.
Few paper designs survive contact with the actual development of the system. Some do better than others, but it's hard to know how an API is going to feel as a developer until you start using it.
So try a few apis on your own, study those you like, study those you hate and think how to make them better, and work on some proof of concept implementations to see how it goes.
I am looking for a good reference (Paper, Blog, Book etc.) on how a good caching strategy could benefit - especially web based - applications. I know it is always application specific but I just want to quote some figures about the performance gains possible (or when it doesn't make sense). Would be great if you had some input for me.
Some pointers with data:
http://www.gear6.com/memcached-resources/papers
http://www.docstoc.com/docs/412119/Technical-White-Papers---Oracle-Coherence
http://www.terracotta.org/ehcache/distributed-cache/ehcache-ex-performance-whitepaper
There's a decent paper (published in the ACM) called "Quick and Easy Cache Performance Analysis". You might find it useful.
If you can't download that paper, let me know and I'll send it to you.
I'm a recent graduate who is looking to get a job doing user experience. Next week, I have a technical interview in which I will be given a website and will have to talk about its usability issues as well as come up with ways of improving the user experience. I feel I have the natural skills to do this and have been doing a fair amount of reading into the subject, but I would like some further advice on how to effectively critique different kinds of websites.
Does anybody have any suggestions of common faults I should look out for, or advice on ways of structuring my evaluation in order that it is relatively air-tight and I do not miss anything obvious?
As I've said before, I'm already doing a lot of reading and I realize that practice makes perfect. However, I'm hopeful that those that have long-term experience with this can help me by imparting their wisdom on gotchas, common issues, and what to look out for in a good/bad website.
Thanks in advance!
How easy navigation is
Whether a user can easily find what he needs without resorting to "search" function. Edge case: whether a user can find the search input field without using the browser's search function (Ctrl+F)?
Whether a site is browsable with images turned off
How many clicks it takes to accomplish an operation. Is that many really necessary?
Are the most important / frequently used features right there in front of the user?
Whether you communicate with the user in geek language
Whether you overwhelm the user with long literary texts where one or two words will suffice
Whether you use standard ideas in your UI. Do buttons, links and menus look like buttons, links and menus? Do they also work that way?
If UI is made up of a limited set of controls with consistent look and behavior? Or each page is unique and has to be learned from scratch?
Whether UI is accomplished with mostly 2-3 colors or uses different colors everywhere to look cool
Also check out the following questions:
Worst UI You’ve Ever Used
What are common UI misconceptions and annoyances?
Why is good UI design so hard for some Developers?
What is the best UI you’ve ever used?
As the other answers have talked a bit about usability I'll mention some things about accessibility (although good accessibility and usability go hand-in-hand).
First of all you need to get the usability correct - a site with poor usability will straight away mean that it will almost certainly also have poor accessibility. Make sure it makes sense, is easy to navigate and is structured meaningfully - for good accessibility that needs to be reflected in the markup as well as visually (so use headings correctly, use things like (strong) instead of (b)old, etc). Automated tools can provide some limited help with this.
Secondly make sure you use the various pieces of markup that are available which will enhance usability (e.g. alt tags on images). Automated tools are excellent for this.
Next if you're going to use technologies like javascript try to use progressive enhancement so that users without those technologies available still have a workable experience. Automated tools won't help much with this.
Finally don't get lured into thinking that an accessible website is a dull boring featureless one - for every user with visual difficulties there will be many more who have cognitive difficulties such as dyslexia. The aim is to make it engaging for everyone, not cripple it for a minority of users (who will likely also be penalised if you start slashing content - for example youtube is one of the most popular sites for blind users).
My thinking process :
See what's different. I mean ask yourself, "is this button here also done that way on youtube/google/basecamp/whatever has been proven good enought".
If it's not the case, I ask myself "does it make sense to do it differently?". If it doesn't make sense, then it shouldn't be that way to avoid confusing the user.
If it makes sense, I ask myself "If it's not obvious, what's the learning curve for the user?", always keeping in mind that "the user" is not IT.
Then I'd see if I can improve it. If I can't, maybe you can't improve it, so even if the control is not perfect it's good enough.
Finally ask yourself "what does the website wants the user to do?". Is it buying something? Subscribing? It's all about figuring out what's the objective. Then see if the website is oriented toward something aiming to complete this objective.
As well as practical ideas about usability problems, you might want to think what kind of process you'd use to do this work (and how it would fit into the company's development process). Would you start out with research? How would you present your analysis and feedback?
What usability evaluation methods do you use?
GOMS?
Cognitive Walkthrough?
Think aloud protocol?
Others? (apart from 'ask your mum' tips that are well covered elsewhere on SO)
Dogfooding. Using our own application we quickly find out which parts are clunky or inconvenient to use.
Log and analyse support calls, and track what parts of the application users have trouble using or finding.
Usability tests. We write down a task, as near to an actual use case as we can, and ask a few users to perform it. We watch them do it, ask them to think aloud while they're doing it, and ask them lots of questions afterwards.
GOMS is way too heavyweight (and too far from reality) for most tasks ... i'd suggest something way more lightweight like hallway usability testing, as advocated by joel spolsky:
http://www.joelonsoftware.com/articles/fog0000000043.html
build the UI out of pieces of paper. create several task scenarios - probably don't expect to cover the entire UI in one sitting. find good test subjects based on target audience (this may be the hardest part). provide said subjects with printed agenda .. provide a human-being to act as 'help system' but otherwise stay quiet .. ask subjects to 'think out loud' - say what their brain is doing (why good subjects are hard to find) .. video what happens and analyze. ..fix stuff, and iterate.