I'm converting a desktop training application to a SharePoint 2007 website. This is a little hard to describe, but one feature of the application is a section of training instructions coupled with a photograph. Imagine a photograph of a kitchen on the left and a scrollable section of text information on how to use the kitchen on the right. The text on the right will be rich text from SP reusable content. The photograph has several dots marked on various places of interest in the kitchen with a little color coded box containing a text description of the point it's next to. When you hover over text instructions in the right section, the corresponding dot for that area of the kitchen needs to be highlighted (a thicker, or wider border on the dot and description box, maybe a lighter background color). So if I hover or click the paragraph about the refrigerator in the right pane, the dot and description over the photo on the left would become highlighted.
My experience with asp.net has been very data driven and the web has become a lot more visually capable since then. Would DHTML, Silverlight, or something else be the best option for this? We cannot use Flash.
I determined either DHTML or Silverlight would be fine. We ended up going with Silverlight 5 because we are more adept to that technology and even though there may not be a Silverlight 6, MS will continue to support Silverlight 5 long enough for our needs (until 2023 or something like that). I gave the jquery MapHilight plugin a shot, but couldn't find any support on how to use it
Related
I'm working in a project of building a responsive website. The painful thing we're having is to deal with the content of the image in different display modes. Please be noted: the image content.
The thing is: in almost pages at PC view, the images are displayed in landscape, with great ratio between width and height. Now when bringing them to mobile view, we have to display it in a different frame. And as you might imagine, now the content of the image was scaled and cropped and then exported to some very weird images on mobile view. Like a wide picture with people are almost in left side, but after being cropped there are only non-sense objects in the picture left.
IMHO, via technical solutions we are only processing the technical attributes of the image (resizing, scaling), we are unable to deal with the image content, that's really a human matter, right?
I'm thinking about 4 solutions:
1 - Despite the customer feelings, we just scale the picture (keep
all content, just resizing it). The output sometimes will be very
ridiculous I guess because of resizing a landscape picture to a
portrait or square one. But that's mostly the easiest way to come up.
2 - Considering to image frame size on mobile view, and auto crop the
picture by picking the center area of the picture. As I said above,
it produced the non-sense picture after all.
3 - Informing customer, whenever they upload a picture, they have to upload 2 copies of it, 1 for desktop view and 1 for mobile view, and they're definitely responsible for the content displaying at front side. Tons of effort need to be spent by customers, but easier for development.
4 - Advanced feature: user can upload only 1 picture, we provide the
different view-ports and a cropper for them to decide how the image
displays on those after being cropped.
I don't have much experience in dealing with these stuff, and not sure how the world out there handling this case. As I see for now Wordpress is only requiring users to upload only 1 picture and it will automatically scale it (my 1st option). Does anyone have experience on this? Can you please share me your solutions and also your thoughts about my above solutions? Thank you.
you can build a simple web application for them to upload the picture and provide your client with a preview of how the pictures with look like for both desktop and mobile. in php, there is the GD library and it is quite easy to use for cropping and resizing.
Apply the 4th and the 1st option so you don't have to deal with it,
Crop and scale with the options you have AND let the customer decide if they want to change it and choose how the image is been displayed.
in case they ask you can say they have the option to fix it, in case they don't want to you already handle the best technological option.
I have a Mobile design to fulfil:
The menu is a fairly standard Accordion setup.
It starts collapsed.
Tapping anywhere on A will expand it to show the A sub-menu.
Tapping anywhere on B will collapse A and expand B.
Tapping anywhere on A Sub 1 will take you to that link.
All standard so far! But the additional Feature is that A is itself a page that the user might want to access!
We have to fulfil this very specific design, so we can't add expander controls, to separate the link from the expand.
I was originally using simple nested <ul> lists and some trivial JS to bind into the onclick events. That was fine for elements that were links OR expanders but that fell apart on bits that were both.
I tried changing the behaviour to exposes the submenu on hover, to utilise the behaviour that I discovered, and documented here: Tablets hover on first click, click on second click
That does technically work, but not very well: you can't scroll the menu properly because touching outside your current expansion will change the selection; the hover exposure of the submenu isn't animated; it generally doesn't actually work well for phones and on a small desktop screen it's completely unusable.
I've looked for ages online for an example or a library that will Just Do This, but nothing fits what I need, and we've been given this very specific design spec.
Currently my only solution is going to be to implement the 2 phase clicking myself in javascript, storing the current state of the element in data attributes and reading those before deciding what action to take on click.
Is there any better way to achieve this?
=-=-=-=-=-=-=-=-=-=-=-=
See here for SO posts about related scenarios for a traditional navbar menu:
Tablets hover on first click, click on second click
https://stackoverflow.com/questions/29354150/deactivate-hover-on-tablet
You just need sit at your computer and watch for responses in about 50 years when all programs will include multiple touch, voice recognition, and thought features to accommodate your functionality request.
Personal experience dictates this problem will not be solved in less then 5 to ten years based on Moore's Law and general apathy on the internet.
I want to create a web page displaying the status of several systems. Each one will be represented by a square box.
The boxes will fill up in either red or green (<50% will be red and >50% will be green).
Can this be constructed in HTML? Can anyone guide me to the best language to use for this if not. Also I have to use ASP.net to do this.
Accessibility is important to me as I'm a physically disabled developer. I'd like to make sure I have a good feel for what it takes to make a site accessible while also being pointed in the right direction for the things I'm uncertain with, or just haven't considered. So, here's what I'm comfortable with right now:
Alt text for images with meaning.
Percentage or font-relative measurements (ems) for those who need to re-size their screens.
Colors with good contrast for those with colorblindness.
Textual representation of any audio/visual material.
Questions:
Should I make a link at the top of the site to jump down to content on every page?
How is JavaScript handled by screen readers?
Is there anything major I'm missing?
WebAim.org is a great resource for all things web-accessibly related. Suggest starting off with their WCAG (Web Content Accessibility Guidelines) checklist.
Quick answers to your qu's:
Should I make a link at the top of the site to jump down to content on every page?
This is currently recommended best practice. (Eventually HTML5 semantic tags will remove the need for this, but we're not there yet. One thing to watch for: if you do use a hidden link, be sure to make it visible again when it has focus, so that sighted keyboard users don't get 'lost'.)
How is JavaScript handled by screen readers?
All depends on what you use it for. The main area for problem is if new content appears that the user is supposed to be aware of (eg. popups, expanding blocks); if it doesn't get keyboard focus, a screenreader may not read it out to the user and the user may not realize that anything has changed. This is one area where it may be necessary to test with a real-world screenreader (eg. NVDA or JAWS) to ensure that it's actually usable. A simple approach is to only have UI appear in response to user request: eg user hits return on a menu item to make the menu appear, don't make it appear merely in response to it getting focus. Then when it does appear, set focus to the first item: this is both expected behavior for menus in most UIs, and changing the focus typically also causes the screenreader to read out the new item, which confirms to the user that something has happened. (Also, if using Javascript to add behavior to existing elements - eg. make a link behave like a button - use WAI-ARIA attributes such as role="button" to let the screenreader know what the intent is so it will read out that role to the user, and will say 'button' instead of 'link'.)
Is there anything major I'm missing?
I think you've got most of the key points already covered above; the WCAG checklist should fill in everything else. One major area that is worth mentioning is to use headers (H1, etc) appropriately. For screenreader users, navigating by header is a major way for navigating a page. Typically when navigating to a page that a user hasn't visited before, the user will hit a hot-key to get the screenreader to bring up a list of headings on that page as a way of 'skimming' to get an overview. Having good link text is also important; ideally links should be self-describing, so you don't just hear "click for more", "click for more" as you tab through a page.
For newer browsers, IE8, IE9, Firefox 3?, and Safari 5 (possibly 4), and newer screen readers WAI-ARIA is the way to go. Among other things it has landmark roles which if you have an ARIA reading screen reader, such as JAWS 12 and possibly JAWS 11 and 10, the screen reader can use to jump around. It can get a bit clunky if you want things to be backwards accessible but is the direction the web is going in. Their are many other advantages to ARIA but that's the one relevant to your question. On a related note VoiceOver for the Mac is supposed to be ARIA compliant as well.
I'm not disagreeing with the selected best answer, but I would spend more time learning about WCAG 2.0 than with the original WCAG specification. Both in the United States and internationally, the Web Content Accessibility Guideline 2.0 are quickly becoming the standard. In fact, the Access Board, the group tasked with defining the guidelines for Section 508, are refreshing the standards to be harmonized with WCAG 2.0.
You can find great information by starting here Web Content Accessibility Guidelines (WCAG) 2.0.
I am for a control that we can buy to crop and annotate images from an ASP.NET web site.
The customer wants to be able to crop, change contrast, etc. AND add shapes (lines, squares, circles, text, etc.) The image quality doesn't need to be all that high.
The images are used for "evidence" and are annotated to explain what is going on, point to areas of interest, etc.
The customer would perfer web based controls because user will be using a thin client with IE 7.
The customer likes Phixr and Snipshot
Disclaimer: I work for Atalasoft
We have webcontrols that can do that. See DotImage
http://www.atalasoft.com/products/dotimage
You can see a demo, download an eval or watch videos tutorials for how to build websites with our controls. It's 100% AJAX -- supported in IE, FireFox, Safari and Chrome.