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.
Related
Not a good way to start, but pardon me if this if off-topic, it seems like a programming question though...
From an ASP.NET website I want to open a page in a new browser that has a toolbar at top and an iframe-like window at the bottom. The frame-like window will support tabbed browsing and load a third party website. The toolbar will have buttons that allow the user to manipulate the HTML (form-fill and web-scrape). For example, toolbar buttons may be "Extract Webpage Data" or "Fill Form".
Ideally it would work with IE, Edge, Chrome and Safari, but an absolute minimum requirement is IE, a more preferable minimum requirement is Chrome and Edge.
I have seen this done, well, by other proprietary software. I do not know if they require a specific browser (like IE where they can install a plugin) or how they do it, that is my question.
So I have narrowed this problem down to three possibilities:
Use pure HTML, Javascript, et al. - Using an iFrame almost works perfectly but the content will not be in the same domain so I cannot access the iFrame's HTML.
Use (or write) a proprietary browser - I do not think you can (or want) to launch an EXE from a web page, plus this seems rather complex in itself.
Use (or write) a plug-in - Probably limits use to IE. I think an IE plugin could do what I want based on other plugins I've seen.
I have past desktop programming experience with a web automation and scripting product, while promising, I don't think they offer what I need:
They have an ASP.NET COM component that runs server side so it does not display an interface to the user but can be used to silently fill and scrape a website based on scripts.
They also have a proprietary browser that shows a user interface and runs scripts to fill and scrape. But this is an EXE, so cannot be launched from a web site.
They have an IE Plugin, that adds a companion popup window that attaches itself to IE. Similar to their browser and runs scripts.
Question - This can be done, I've seen it, but what is the mechanism? I'm leaning to an IE plugin.
If plugins are the answer, chrome has extensions, is that a possibility?
I work on an application similar to Google event calendar.
Name of the application is My Team Event Calendar .
Developed this using jQuery Full calendar plugin.
In a calendar ,for each day ,i would display which teammember of mine is outofoffice(is an employee workfromhome/sick/vacation).
For each of this outofoffice status,i have an icon,displaying the purpose of it.
I have 72 around outofoffice statuses ,which would get icons source from database\
I have all 72 stauts with their associate image icon source in db as "images/pill.png"
Every time ,i get the information from server about a team .for each day i would get team member name,out of office status and image associated with the status.
Consider if my calendar is full for whole 31 days ,and for each day i would have about 10 employees. For each of this out of office status ,i would get a image (this means many http requests for image icons for out of office status).
Can you please suggest is it good to maintain css image sprite.But i have a disadvantage at any point of time a new leave type can be added with new image icon ,which imposes an immediate change in the image sprite.(maintaining/modifying an image sprite is not that easy)
If not image sprite can you please suggest what would be a better solution here
If I'm understanding your scenario correctly this would be an excellent place to use a sprite. A large set of small images is an ideal use case and using a single sprit will reduce HTTP traffic significantly. Sprites may seem like a little overhead initially but it's not bad once you get used to it and the performance is well worth the few extra minutes to compose the sprite.
Keep a PSD (or some other original source) for the sprite handy. When you need to make edits, add a new icon, etc. then update the PSD and export your new sprite PNG.
Another option to consider is icon fonts. You might look at something like Font Awesome, Bootstrap's Glyphicons or a tool like IcoMoon. Icon fonts have a lot of advantages, chiefly scalability and colorization. If you don't need that, though, sprites work just fine.
Im trying to implement a mini browser in adobe air. The browser should work in the same ways as a mobile phone browser, i.e. fit the width of the website to a certain width(specified within the html component) and leave the height to be scrollable.
I have managed to do a mini browser by using the scaleX,scaleY properties of the mx:HTML component however these make the websites look unreadable.
I have also tried setting the css3 zoom property, and that works fine, but it only zooms out certain elements, therefore messing up the site layout.
My question is: Is there a way to make a mini web browser which shows the full content of the website?
Thanks for your help
Air browser cannot be scaled without have an horrible look (no anti-aliasing).
A few years later but here is what I ended up doing:
The requirement was to show the full website that person B was looking at so that person A could guide them through the site. Due to all the limitations of the Adobe AIR Browser we ended up using IECapt (http://iecapt.sourceforge.net/) within an external process to capture the screenshot and send it back to AIR.
This is all well and good, but IECapt is quite out of date as well so recently we have started to look at the using Chromium (http://www.magpcss.net/cef_downloads/) as an ANE within our application and with that we can alter the zoom and dimensions of the page while still being able to keep it up-to-date.
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.
While Handheld option is available in CSS then why some people use different subdomain and make different site for mobile?
I second what Justin Niessner said. Also, the mobile version of a site is usually structured differently from the "main page". Other content may be displayed on the front page, an only a selection of menu items, or a whole different menu altogether. Videos have to be embedded differently, images as well, Javascript effects altered and so on. Using different style sheets mostly just won't cut it.
My guess is to make the distinction more apparent to the user.
That, and the Blackberry Browser (and possibly the iPhone) identifies itself as a mobile device (depending on settings)...but could theoretically be able to display the full page. Using CSS, you're also depending a lot on the mobile browser to do the correct thing with your page.
You'll provide a much more reliable interface if you let the user specify the experience, not the site.