A client asked me about using Vuforia in order to recognize logos on the shop windows. Basically, they want to use logos as a QR.
Is this idea viable? Will it work pretty well? Can you tell my some alternatives to Vuforia about this?
Recognizing logos is hard.
Basically all image recognition algorithms rely on the same principle: trying to recognize "interest points" of the image. These interest points can for example be blobs or corners; in short, we want to look for places in an image where "things happen", compared to (for example) a large solid area painted in the same color where there is not much information to grab.
This comes to trying to recognize discriminant "details" of the image.
When applied to logos, this method tends to fail due to the fact that logos often don't have enough of such "details". Take the Nike logo for example: if corner detection is applied to it, it will only find 2 corners (the 2 ends of the accent). Blob detection will probably give no result at all. This is an extreme example, as the Nike logo is really simple, but even on more complex logos there will often not be enough details for recognition to work.
As for Vuforia: it works in this exact same way, and their web interface (Vuforia Target Manager) is very clear about it: when you upload an image on it for recognition, if there are not enough details on it, it will either warn you that results may be poor or simply reject the image.
To conclude: you can run some tests, it's still the best way to be sure of it, but I wouldn't expect great results. It will probably work for detailed logos, and fail on simpler ones.
Hope this helps!
Related
I am trying to make my app accessible in ios. I have some large complex images (flowcharts and tables). How would I go about making this image accessible if there are different elements within the image? I want them to be able to click on different parts of the image to hear different accessibility hints, rather than one hint for the whole image which may not be very helpful.
I thought about making blank labels and placing them over the image in the right places and writing the hints in these blank labels, but just wondering if there is a better way to do it.
Any suggestions?
You are trying to make the contents of an image accessible. The best solution would be to adopt the UIAccessibilityContainer protocol and return accessibility elements representing each node in the flowchart. The Accessibility Programming Guide for iOS contains a section titled, Make the Contents of Custom Container Views Accessible. By adopting the UIAccessibilityContainer protocol, you can describe arbitrary regions of the flowchart as you would any view.
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.
I'm also interested in more general thoughts, but here is my specific problem. In an ASP.NET web app, I am connecting to a 3rd-party via API. The 3rd-party requires that the user login and answer a few configuration questions to set this up. All of the questions except one the user can just choose the default. On one question if the user chooses the default option, my app won't work with the 3rd-party. It is a limitation of their API. It is on their list to fix, but who knows when or if they actually will?
So what is the most effective way to give the user instructions in my app that they will follow once they go to this other site? Right now I have a screenshot with the option circled in red, follow by some descriptive text. What other techniques have you used in a similar situation?
Red text is the default mechanic in UI design to indicate importance (which is why it's used for errors so often).
Asterisks are the default choice for indicating required input.
Avoid flashing, and other garish-looking visual mechanics.
If this extends beyond a one-time inquiry, you should look at reading some good GUI books, like Don't Make Me Think: A Common Sense Approach to Web Usability and Designing Web Usability, both seminal books in the field.
I think you're headed in the right direction. I would make sure that your illustrative screenshot is large and easy to see the relevant details on. Also, some highlighted (classic yellow background ala 37 signals?) text to emphasize the importance of NOT selecting the offending option would be helpful.
Also, make this screenshot and highlighted instruction text, the VERY last thing they see before you forward them to or present the 3rd party site. Maybe make the action link (button, link, etc.) explicitly outline their acknowledgment of the thing not to do.
Maybe even, have fun with the caption like...
"I understand that choosing the default option above won't work."
Just some thoughts.
Unfortunately, nothing you can do will prevent idiots from choosing the wrong thing anyway. Basically, you can't make it idiot-proof.
This is more for GUIs but (depending on how critical this is) you can force users to type "I will choose xyz" before a redirect.
Is there a way to set a default on your end to get around this problem altogether? For example, picking some random setting initially that they could change in a profile of some kind that you can store on your end.
I've typically seen a red asterik(*) used for marking required fields on web forms if you want to not pre-select some value for the user for another way to try to solve this issue.
I know you want abstract, generalizations but there is no one true answer for what you're asking. I mean, what kind of content are we dealing with? Is the content broken up over multiple pages (or should it)? What kind of users generally use the form?
I know I've dealt with similar problems in dozens of different ways. Ideally you want not start treating your users as complete retards straight out of the box (just move to that progressively as they fail tasks), but you also want to be clear on what's going on.
The really high level (and obvious) ideal is that you want to make the instructions stand out to your punters. Colour change and standard icons do this (often poorly). However, changing the background colour of instruction text (to say a light gray) with a large icon (like a yellow sign with an exclamation mark) tends to focus the eye.
Another idea in your situation is to break the content in two. This might be done physically (press next to continue) or you might just colour code that hole part of the element a different colour to notify the user that they need to treat this differently.
I am working on an ASP.Net web application that must print dynamically created labels on standard Avery-style label sheets (one particular size, so only one overall layout). The labels have a variable number of lines (3-6) and may contain either lines of text or a graphic barcode image.
Our first cut, that I inherited, used monospaced fonts to reduce the formatting issues, but that did not allow enough text to the fit on the labels and the customer was dissatisfied. Basically it was formatted text.
My next version used TABLEs, DIVs, CSS, and a bit of JavaScript calculations to format the labels using proportional fonts. It still required a bit of tweaking (the user had to set their print margins correctly and turn off the print headers and footers), but it seemed to work.
However, it seems that there are some variations on how different printers render the text (WYS ain't WYG), so even though we tested on different browsers using at least two different printers (an inkjet and a laser printer), some user's labels don't line up. Slight margin variations can be adjusted by adjusting the margins on the page setup dialog, but the harder problem is that the inter-label spacing can be off by a tiny fraction of an inch, so that if the first label is pretty well centered, by the end of the page the label text and images have crawled off the top or bottom of the labels.
We are about to the point of switching to generating Word, Excel, or PDF output which is going to take quite a bit of development time and possible add extra steps in the printing process.
So, does anyone have any suggestions on how to do an HTML/CSS layout that will precisely render on different types of printers? I don't really care if the line/word breaks are a bit different, but I need to be able to predictably position the upper left corners of each label area.
Right now the labels flow down the page in a table and we have been tweaking the box model of the cells and internal DIVs to make them a uniform height. I suspect that using absolute positioning of each element may be the best answer, but that is going to be tricky as well due to the ASP.Net generation of the label elements. If I knew for sure that would work, I would rather try it than throw away everything we have to go to a different generation method.
Slight Update:
Right now I'm doing some tests with absolute positioning - setting only the top and left coordinate of a containing block element. So far there are minor variations on the offset onto the page (margins, paper alignment, etc.), but all browsers and printers tested put the elements in exactly the right spots relative to each other. I appreciate the PDF tips, but does anyone know of additional "gotchas" on using absolute positioning this way?
Update:
For the record, I rewrote the label printing portion using iTextSharp and it works perfectly - definitely the way to do this in the future...
Forget HTML and make a PDF. HTML printing is extremely variable - not just across browsers but across different versions of the same browser. PDF is a lot easier.
Even if you get it exactly right with one browser / font setup / printer / phase of the moon, it will be the most fragile thing you've ever had to maintain. No matter how long you think it will take to make a PDF (and it's not really that hard as there are some free libraries out there), HTML will ultimately take a lot more of your time. PDF readers are widely deployed and print more consistently than even Word files.
The web is not a format that is guaranteed to get consistent print results. Given the standard support for label printing with MS Word, and the relative ease of automation and generation, I would strongly recommend going that route.
I'm not aware of ANY method to get percise printing across all types of browsers, operating systems, and printers when using web content.
"precisely" and "printing" aren't two words that really work together that well. I did an OCR/OMR application a year or so ago, and even when building a PDF I saw significant differences between different print drivers and such. Because of that, my gut is to tell you that you might not have 100% success.
If CSS and layout issues don't work that well for you, you might need to resort to building the labels as images using GDI+ -- at least that way you can use GetFontMetrics() and such.
Good luck!
I had a similiar issue and the answer is you can't do it. Instead, I generated a PDF file in realtime using iTextSharp and passed that to the response.
Using SQL Server Reporting Services, I generate a PDF to send to the printer, but it can be seen as HTML on the screen using the control you can include in your web pages. There are RDLC files that are available on the internet to print to various Avery formats.
I rewrote the SharpPDFLabel code that was mentioned back in 2011 this week as I needed it to be a lot more flexible (and to work with the current iTextSharp library).
You can get it here:
https://github.com/finalcut/SharpPDFLabel
I added the ability to specify the contents of each individual label if you want (or to continue creating a sheet of identical labels too). By extending the LabelDefinition class you can specify the layout of your labels pretty easily.
I also struggled with the HTML/CSS approach due to the inconsistent printing behaviour across browsers.
I created a C# library to produce Avery Labels from ASP.NET which I hope you might find useful:
https://github.com/wheelibin/SharpPDFLabel#readme
You can add images and text to the labels, and it's easy to define more labels types.
(I use it for barcode labels, the barcode is generated as an image and then added to the label using this library.)
Cheers
Add a few options to your app that let users adjust spacing for their particular configuration. You could include this right on the label if you want, and style it away via media selectors, but you'll probably want to persist them somewhere, too.
Flash is also good method to push a printable like a label albeit a little more complex to implement and maintain. In most cases it displays much quicker than a PDF and you can embed it into the design of the page and simply add a "Print" button within the flash.
I did this several years ago when we were using HTML and PDF to generate confirmation receipts. HTML is "ok" but is at the mercy of the end users web browser so we quickly dumped that method. PDF's are good as long as they have a PDF reader, which to our surprise a lot of our customers did not. So that was dumped as well after we switched to a FLASH version using a simple flash movie that included a few dynamic text areas and a "print" button. I communicated the data between the page and flash using a few flash vars. You can also use web service.
When I need something more than just simple text I use the free community edition of the PDF Generator component from DynamicPDF.com. It works great and is very quick.
I just went through the same thing. Ended up switching and making a short little JSF app (running on Glassfish) that uses JasperReports to print directly to the lable printer. Push button, instant label at the printer, don't even have to view it on-screen if you don't want to since Jasper can directly output to printer (as well as PDF in browser).
I was listening to a recent episode of Hanselminutes where Scott Hanselman was discussing accessibility in web applications and it got me thinking about accessibility in my own applications.
We all understand the importance of semantic markup in our web applications as it relates to accessibility but what about other simple enhancements that can be made to improve the user experience for disabled users?
In the episode, there were a number of times where I slapped my forehead and said "Of course! Why haven't I done that?" In particular, Scott talked about a website that placed a hidden link at the top of a web page that said "skip to main content". The link will only be visible to people using screen readers and it allows their screen reader to jump past menus and other secondary content. It's such an obvious improvement yet it's easy not to think of it.
There is more to accessibility and the overall user experience than simply creating valid XHTML and calling it a day.
What are some of your simple tricks for improving the user experience for the vision impaired?
Creating accessible pages is something that is hard to think about if you have never done it. However, once you learn the basic concepts it is very easy to do in 95% of the cases. I will mostly be repeating what others have said, but:
Only use tables for tabular data
Make sure you use the semantic tools available to you via HTML. This means using TH with a scope attribute. Use <em> instead of <i> and <strong> instead of <b>. Use the acronym and abbrev tags. Use definition lists. I can expand on these things if anyone wishes.
One of the most important things is to use the label tag on input fields. For every input field, radio button, checkbox and textinput you should have:
<label for="username">Username:</label><input name="username" />
Add a "skip navigation" or "skip to navigation" depending on where big chunks of text are. If you are working on a government site this should be second nature that everything you're creating allows you to skip repetitive information.
Do not use colors for emphasis.
Ensure that all of your text is resizable. This pretty much means don't use "px" in your css.
I will re-emphasize this: create semantic pages. Use H tags for your titles. Use ul/li for navigation.
Use the alt attribute on all images. If you have a spacer gif... well.. don't. Otherwise, explain what the picture is of and what its significance is to the content it is associated with. don't use "a chart" as your alt tag. Use "Chart of YTD finances: $5,000 Q1, $4,000 Q2, $8,000 Q3" or something similar.
Provide closed captioning or transcripts for all audio and video components
The key here is to provide those with visual, hearing and motor impairments the same experience as those with standard physical capabilities. If you can't tab into a field, a screen reader can't either. If you can't click on the text next to a check box to select it, the screen reader doesn't know the text is related to the check box.
You should frequently view your site without stylesheets (ctrl-shift-s if you have Firefox and the Web Developer Toolbar) to see if the page makes sense. If it doesn't make sense to you as a sighted individual, it won't make sense to someone using a screen reader.
Check out Fangs
Fangs is an in-browser tool for Firefox that emulates what a screen reader “sees” when visiting a Web page. Its function is simple: to output a transcript of what a screen reader will read out to a user when a Web page is visited. It’s a helpful tool for quickly analyzing if you’ve structured your content effectively so that it’s understandable and usable by vision-impaired individuals, without forcing you to learn to use (and purchase) a screen-reader application such as JAWS or Windows Eyes.
It's been awhile since I've been at a job where we had to adhere to Section 508, but here's what I remember that hasn't been touched on by the other posters...
Only use tables for data. Do not use tables for layout if you can avoid it.
When using tables for data, your column headers should be nested in TH tags and you should use title and scope attributes. Your table tags should use the summary attribute.
Images should all have a value for the alt attribute that describes what's going on in the image and if the image serves no purpose (it's a shim image or something similar) then the alt attribute should be set to empty string.
Try using a text to speech reader and/or navigate only through the keyboard and/or turn off stylesheets. I believe you need to purchase JAWS, but I'm sure there are free screen readers out there. You need to experience a site through a screen reader to truly understand how difficult most web pages are to navigate without the cues that screen readers interpret.
"Vision impaired" includes colour-blindness. I used to work with someone who couldn't distinguish red from green too well, so any applications that used a traffic-light style interface was very difficult for him to use. In the industry we were working in, alerts in rows were colour-coded, so another form of display was useful for him, such as an extra column in the row with the text of the alert type ("emergency", "warning" etc).
Biggest problem with screen readers is usually tables to position things on your page. Screenreaders can't really handle those. Put stuff in div's in your html and put them in a sensible order. Then position the div's on your page with css. Use tables to display content that should be in a table.
The code for many web pages is structured as:
Header
Top Navigation
Left Navigation
Content
Footer
When structured this way, then the hidden link for "Skip to Main Content" is beneficial. However, with CSS layout, you may be able to reorder this so that you have:
Content
Header
Top Navigation
Left Navigation
Footer
You then use CSS positioning and floats to move these different elements around on the screen to make the page look the way you want it to look.
The main advantage to structuring a web page in this way is that if the browser doesn't support the CSS, then the content is first on the page. In addition to screen readers, this is beneficial for mobile devices and search engine spiders.
For partially partially sighted we need to make sure text is not excessivly small and contrasts the background color substantially. We should also make sure text is resizable by using relative sizing units such as em's rather than absolute units like px's (although, in my opinion, this is becoming less of an issue as browsers are increasingly favoring zooming over text resizing).
For users of screen readers, it's helpful to get a good idea of the way screen readers are actualy used. The following article presents guidlines based on observations of blind people browsing the web using screen readers; it's a little out of date now, but gives you a good feel for what will help screen reader users, and what won't:
http://redish.net/content/papers/interactions.html
Additionally, the American Foundation for the blind have a section of their website dedicated to advice for web developers on how to cater for vision impaired users.
In addition to the visually impared, we need to consider those with disabilities that prevent them from using a mouse, and also those with neurological disabilities. If anyone can provide resources giving advice on how to cater for those individuals, that would be great.