I have a pretty simple app on the web (written in Flex) which is very straightforward to use once it has data inside it. The steps to get data inside it are themselves also pretty simple, but not at all obvious to my audience when they first log into my app.
I have been wrestling with how to communicate the data setup process to my users without referring them to a separate help. I also don't want to clog my lovely, elegant UI (which has uniformly been praised for its clarity from my current users and matches their processes very well) with wizards, or worse still an annoying animated paperclip.
I have a very rich set of tools available for the web UI but I am looking for inspiration and wondered if anyone had experienced good web-based, intuitive, unobtrusive, genuinely helpful process/usage instructions embedded in an application and could point me to a link so I can take a look for myself.
Failing that anyone got any bright ideas? There are about 5 steps involved each one visiting a different page of the existing app to enter/upload data.
Have you taken a look at:
http://www.askthecssguy.com/2007/03/form_field_hints_with_css_and.html
I believe there is a jquery or prototype or mootools or whatever framework that goes a couple steps beyond the above and walks a user through what to do. My google-fu isn't coming through right now so I can't seem to find it.
You could display the links to the data setup pages in a small strip on your main page like this (pardon the ugliness - this is just a usability idea):
alt text http://www.freeimagehosting.net/uploads/052b13acb7.jpg
The steps they've already completed are greyed out (I assume they don't have to complete these steps in sequence). When they mouse over a step they get a brief description, and then full details when they click through to the actual step page. You could have descriptive icons for each step instead of hyperlinks, of course.
Related
I'm wanting to make an application with node have a cli interface, as it needs to be ran in a terminal. I want to split the terminal into several sections, one with some identification as to who is viewing the application, another with some other random info, a menu on the side that you can use the arrow keys to move up and down the options, a main logs section, and another that you can type, and press enter to send text in. I've drawn up a little diagram of how I want to make it: (I know this looks awful, it was made in mspaint)
I've gotten the console input part working by using the readline module, but I don't even know where to really start with designing the terminal how I want it, setting text in certain sections, etc. I've looked around at things like terminal-kit, and clci, but either they didn't seem like what I wanted, or their docs/examples were a mess.
I would prefer to do this with node only, not using another application in another language, as all of the stuff going to the console sections will be from the same node application.
I found the blessed library at https://github.com/chjj/blessed. It is based on the ncurses library (written in C, https://en.wikipedia.org/wiki/Ncurses) and it allows you to create different sections with specified heights, widths, etc. in different areas of the terminal. Very useful in theory, and you can follow the advice on the github page, clone the repo into your desktop, look into the test folder, and then run the different files ie. node test/widget-form.js to see the different types of interfaces that you can create in your terminal.
It hasn't really worked for me, because it keeps crashing on my end, but I see that there are a lot of open pull requests and that people are still trying, so it might be working for some, although I think that the usage for some "widgets" is limited. The next best thing I can recommend is either blessed-contrib or neo-blessed, the former being developed by some dude from Facebook. Blessed-contrib is newer so you might have more luck with it, but it's essentially made for visual output, so you'd be able to create a section for a log, a selection menu, a paragraph section, etc. but nothing to create an area where you can input text (so 4/5 of what you need), based on my reading of the documentation, which you'll find here https://github.com/yaronn/blessed-contrib.
I personally think it's dope. Good luck with it, I'm going through the motions of understanding the documentation better myself, and I've delved pretty deeply in it, so feel free to reach out if you need any help.
On another note, let me know if you've found anything else other than the resources I mentioned, which would be very helpful for me, as the alternative right now is for me to code the text user interface myself using C and the ncurses library, which I'm trying to avoid if it's unnecessary :)
EDIT:
I found something for you and for me that might send us in the right direction. Good news. This is the gitter-cli. It uses the library I mentioned above blessed. If you clone the gitter-cli's repo, follow the instructions to get a token and create an account, and join one of the rooms (you can find the name of the rooms like 'gitterHQ/javascript' on the gitter.im website), you'll see that the chat works. There might be some optimizations I'm not aware of, but I recommend just delving into their code while also delving into the blessed documentation to understand how it works. It should give you an idea of what to do next.
It took me a lot of hours to find all these different resources and connect the dots so you should definitely check them out.
I'm new to Sketch and Flinto but have come up to speed after prototyping fully functional designs in HTML, CSS and JS.
Q: If you build a prototype with Sketch and Flinto, how can you export or save it so that others without Sketch can view it? Is that even possible?
PS: Additionally, where could I find a good online course (free or paid) about "Sketch 4 from srcatch for beginners"? I have looked and googled, and I purchased the Udemy course (but even though they say it's OK for beginners, they jump right in, making a lot of assumptions about knowing Sketch already.
There are a lot of ways to share your Sketch project, it depends if you want to share your prototype with the client or hand your deliverable to the developer.
I recommend using Invision, it is an online tool, you don't have to download any software, you just share your project with a link. With a free account it allows just one active project at a time, but if you want to upload a new project you can just store the old one. Invision is a great tool for both clients and developers, who can see the interactive prototype with transitions and animations, make comments, and view the code with inspector.
Another great tool for handing the deliverables to developers is Zeplin.
About Flinto, to share your prototypes you can record the preview window and share the mov/gif file, or you can share the flinto file to a phone and open it with the Flinto viewer app.
There are a lot of transitions that can be done with Sketch plus the plugin Craft, maybe you don't even need to use another tool like Flinto.
To learn about Sketch there are a lot of youtube channels I can recommend: Sketch Together, Joseph from LearnSketch.com, Jesse Showalter, CharliMarieTV, The Futur.
Hope this was useful! Keep on learning!
I'm trying to program a Webpage, which allows to edit a text document simultaneously.
To program something like a Chat in Node.js is not very difficult, but working on the same text makes it kinda tricky.
I thought about sending the char position and the changes characters, but if someone types something previous to the change, the change would be placed on the wrong position.
What's the best way to exchange Modifications between my clients?
You should use Socket.io to have make your Real-Time application.
I just founded a nice blog article which speaks about real time edition, see here.
It's also providing a link to the github project and to an open source online editor project.
Take a look and try to understand how they do stuff like this, good luck !
Two people cannot be manipulating the same object at the same time from a different place. You basically have two choices.
1. Let them take turns with the object
2. duplicate it if they both want it, but that doesnt sound like it would end well
The web site that we're writing needs to be "Accessible". The trouble is, while we understand the general conepts (semantic latout, alt text on images, light on Javascript, etc etc), we don't really have much knowledge of what screen reader products or other accessible browser are actually on the market and/or in general use, nor how to test against them.
So the questions are:
What products do we need to know about?
Would it be sensible (or even useful) to get hold of them to test against?
Are there any QA processes we should be looking at to assist us (we do a lot of automated browser testing [Selenium] to ensure we don't break anything for regular users; can we/should we do the same for screen readers?)
Thanks in advance for any tips.
See this question
As the question implies if you want good screen reading testing you either need to hire someone to do the testing for you that has a lot of screen reader experience or invest the time in having developers and or QA learn a screen reader well. To my knolidge there is nothing like Selenium that can simulate how a screen reader handles a website. FOr general info on accessibility see
http://www.w3.org/WAI/gettingstarted/
This appears to have a lot of good information and covers all kinds of accessibility, not just blindness.
For a list of tools to check html accessibility see
http://www.w3.org/WAI/ER/tools/complete.html
Although these tools will help they are not a substitute for screen reading testing. For a discussion of some of the problems with relying only on automated tools see
http://www.webcredible.co.uk/user-friendly-resources/web-accessibility/automated-tools.shtml
In addition to Jared's answer: For the non screen reader visual accessibility testing, I've found that a simple and easily available test tool is a gray scale printer. This will let you know (roughly) if you have enough contrast for those who have a form of color blindness or other issues with contrast, etc and whether you've snuck any images in that are relying too much on color for information. It's not the be all and end all, but it's an easy first test.
Since you're already using Selenium to test your site, you can easily integrate something like Continuum, which can scan a page for accessibility concerns that would be noticeable by someone using assistive technologies, into your existing test framework. There's API documentation if you'd like to roll your own solution, or free Java and JavaScript sample projects on webaccessibility.com you can use for inspiration.
As others have noted, automated accessibility testing isn't going to catch everything as nothing compares to manual testing done by experts, but it's a good idea to do some kind of automated testing just to cover your bases, and there are a wealth of technologies out there these days that can help you do that very easily.
I want to code a trading bot for Magic: The Gathering Online. This bot should wait until someone offers to trade, accept, look through the cards available from the other trader (the information is shown on screen), and perform other similar functions. I have several questions:
How can it know that someone is offering a trade?
How can it know that the other trader has some card (the informaion is stored in pictures)?
I just cannot imagine right now how to do it, I have no experience with it, until now I've been coding only console programs for my physics neŃessities.
First, you should note that some online games forbid bots, as they can give certain players unfair advantages. The MTGO Terms of Service do not seem to say anything about this, though they do put restrictions on anything that might negatively impact the service. They have also said that there is a possibility they will add an API in the future, so they don't seem to be against the idea of automation, but are not supporting it at the moment. Tread carefully here, but it looks like it should be OK to write a bot as long as it is not harmful or abusive. This is not legal advice, and it would be a good idea to ask the folks who run MTGO for permission. edit since I wrote this, it has been pointed out that there are lots of bots already, so there should be no problems writing bots.
Assuming that it is not forbidden by the terms of service, but they do not have an API, you will have to find a way to detect what's going on, and control the game automatically. There's a pretty good series of articles on writing poker bots (archived copy), which has some good information on how to inject a DLL into an application, scrape the screen, and control the application. That might provide you with a starting point for doing this sort of thing.
You might also want to look for tools that other people have already written for doing this. It looks like there are several existing MTGO bots, but they all seem a bit sketchy (there have been some reports of them stealing passwords), so be careful there.
Edit
Since this answer still seems to be getting upvotes, I should probably update it with some more useful information. Since writing this, I have found a great UI automation system called Sikuli. It allows you to write programs in Python that automate a GUI. It includes image recognition features which make it very easy to recognize buttons, cards, and other UI elements; you just take a screenshot, crop it down to include just the thing you're interested in, and do fuzzy image matching (so that changing backgrounds and the like doesn't cause the match to fail). It even includes a custom IDE that allows you to embed those screenshots directly in your source code, so you can see exactly what the code is looking for. Here's an example from the documentation (apologies for the code formatting, doing images inline in code is not easy given StackOverflow's restricted subset of HTML):
def resizeApp(app, dx, dy):
switchApp(app)
corner = find(Pattern().targetOffset(3,14))
drop_point = corner.getTarget().offset(dx, dy)
dragDrop(corner, drop_point)
resizeApp("Safari", 50, 50)
This is much easier to get started with than the techniques mentioned in the article linked above, of injecting a DLL into the process you are debugging. Sikuli runs entirely at the UI level, so you never have to modify the program you are automating or worry about changes to the internals breaking your script.
One thing it is a bit poor at is handling text; it has OCR features, but they aren't all that good. If the text is selectable, however, you can select the text, copy it, and then look directly at the clipboard.
If I were to write a bot to automate something without a good API or text-based interface, Sikuli is probably the first tool I would reach for.
This answer is constructed from my comments.
What you are trying to do is hard, any way you try and do it.
Arguably the easiest way to do it is to totally mimic the user. So the application presses buttons, moves the mouse etc. The downside with this is that it is dependant on being able to recognise the screen.
This is easier if you can alter the games files as you can then just skin ( changing the image (texture)) the required cards to a single unique colour.
The major down side is you have to have the game as the top level window or have the game running in a virtual machine. Neither of which is ideal.
Another method is to read the processes memory. You may be able to find a list of memory locations, which would make things simpler, otherwise it involves a lot of hardwork, a debugger to deduce the memory addresses. It also helps (a lot) to be able to understand assembly.
The third method is to intercept the packets, and alter them. This is easier that the method above as it (at least for me) is easier to reverse engine the protocol as you have less information to deal with. It is just a matter of setting up a packet sniffer and preforming a action with one variable different (for example, the card) and comparing the differences.
The thing you need to check are that you are not breaking the EULA. I don't know how the game works, but most of the games I have come across have a EULA that prohibits (i.e. You get banned) doing any of the things I have mentioned.