Related
First of all, I want to appreciate the work for the SCIDvsPC Project. I know that the basic SCID one has been discontinued many years back and the developer have done a great job with expanding it and doing his share for the Chess Field. We have a Minor Project to do in this 6th semester of our college. We've decided to start a project on a Chess Next Move Analyzer that is based on variety of filters and implements Self Learning and Machine Learning.
I've been researching over the project idea for the last 2 months. Actually we need to import several games defined on some filters and read and analyze from the PGN file generated. For example, if the user chooses to get the next best move predicted according to the rating range of 2000-2500, our program should only export and analyze the PGN files that have both the opponents from this range only. I know the project can do all this but I'm confused over how to automate this. I mean I have to manually enter the moves and then click on 'Generate PGN' but how to make my program do this ie take input from the user (like first 3 moves), make the project run these moves (what I had to manually) and then generate the PGN file and keep it in a folder.
I've surfed the net about interacting with GUI elements in Windows (we have no problem in working with Linux either) and came to know about Microsoft UI Automation, Python, Java and C# softwares and something like COM. Do the software support COM or any one of these or have you already developed some functionality like this? Please can you guide me over this?
If asked to Generalize this what I want to do is to interact with GUI Elements, be it any application. Take Notepad as an example. Suppose I want to open a file on it, find and replace a particular word. Now, I know how to do this manually but when I have over thousands of file I need some kind of program to do this for me. Do some specific programs like SCID in my case has some feature (read bit about COM) pre-built to handle this? In which programming language domain does this come into? Is using Linux help me more?
Take Notepad as an example. Suppose I want to open a file on it, find
and replace a particular word. Now, I know how to do this manually but
when I have over thousands of file I need some kind of program to do
this for me. Do some specific programs like SCID in my case has some
feature (read bit about COM) pre-built to handle this?
Your situation sounds to be quite specific so I doubt whether you will be able to find a pre-existing program to do this for you. Meaning: you'll have to code it yourself.
In which programming language domain does this come into?
Well, this could probably be done in many, many different programming languages. A simple shell script would be able to achieve the Notepad example you gave.
Is using Linux help me more?
No, your goals seem to be pretty achievable by a simple shell script, whether you write it in a Windows, macOS or a Linux distro.
#SB87 gave you some useful hints, I'd like to expand his answers.
Sorry, I don't think you know what you're talking about. Reinforcement learning (better term than self-learning) and machine learning are not something suitable for a college project. It's at the PhD or research level, consider getting yourself into university before even thinking about anything like that.
UI automation is possible, but error prone and slow. If you want to do it, you'd write a console program. You mentioned something about user inputs, do you mean you want to apply machine learning on user mouse-keyboard inputs? It's not going to work. Machine learning for chess requires hundreds and thousands of training set.
I think you should downplay the project and focus on something you can achieve.
For common elements, such as a logout button on a website, save button in an application, need to be presented to users in an standard, easily discoverable way. How do you go about deciding where in your application to place these elements? Do you research similar apps and try to follow convention? Is there any database that attempts to track the use of these common elements or is this too hard to capture?
The goal is to put UI elements where users expect to find them. You want to leverage the knowledge that they already have about how applications work.
So, looking at the the UI elements for the OS that you are targeting is helpful. Unfortunately, there are some key differences here between Windows and Mac, you will have to pick one or switch based on the OS if you target both.
Looking at applications that are similar to yours is generally not a good idea unless you believe that people using your product are already using these other products and you want them to switch.
Instead, you look at products that are complementary to yours, or products that you expect everyone is familiar with. At one point it was a good idea to look at Excel and Word to know how an Windows application should work; But I don't think that the current versions of Excel and Word are a good model, they deviate too much from the way the OS works. You could still use older versions - before the ribbon, if you are targeting Windows.
It's best to be a bit conservative, choosing applications that have been out for a while and people are likely to be comfortable with rather than chasing the latest design innovations that are coming out of Apple and Microsoft.
I research similar apps and try to follow convention...
E.g. logout goes up in the top right near the "X"/close in most applications
Save/Edit buttons towards the bottom of the thing I'm editing... since contextually they happen after I finish the editing I just did.
Then again, you have apps like Outlook... that have the send/save buttons at the top.
In general though... I have application-wide actions (e.g. login/logout/help user info at the top)
Item specific tend to be inline or just after the item they are adding/editing.
I totally agree with leveraging knowledge that the user already has. Every techie is (or probably is) familiar with http://www.dice.com. It frustrates me to no end to see that their website is designed with the logout "link" (not even a "button") at the very BOTTOM of the page. In this age of security conciousness, what a place to put a logout link ???
I have used DeLorme Street Atlas USA mapping software ever since Windows 3.1. About five or so years ago, they changed their entire user interface, moving AWAY from all of the features that make application software in the Windows environment easy to learn and navigate and SIMILAR from one application to another, and TO a totally foreign user interface, unique to their individual product offering.
Was it necessary ? probably not... What was it's impact to the current user community ? probably not thought about... What was it's impact to someone new to Street Atlas USA ?? Probably LESSENED the adoption rate of the software product, because it looked so foreign compared to a user's already-used applications developed with the common Windows-based look and feel.
Although books can be written on how "we" dislike Microsoft, the value-added benefit to Windows since it's infancy with Windows 3.1 was that you could create totally different software applications, but have a SIMILAR navigation style threaded throughout all of the applications, LESSENING the new application learning curve, and INCREASING the adoption rate amongst software applications for the Windows user.
Leveraging positive current user knowledge can only increase the adoption rate of a software product. Why re-invent the wheel, when the current wheel is known and adequate ?
Background
I'm at the planning stages of a DIY project that'll help me automate some hardware at my house. It's probably also worthwhile to mention that I've got almost no experience with web-related development.
The Basics
http://img7.imageshack.us/img7/4706/drawingo.png -- I can't seem to embed the diagram.
In order to simplify management, I want to implement my UI in the browser.
The meat of my application will reside inside a Windows service or Linux daemon; this does not mean, however, that I'm after a cross-platform solution -- I'm not tied to any particular platform, so I'll pick one (probably based on the responses that I get) and stick with it.
I would prefer to use "free" tools (e.g., LAMP/WAMP), but it's not a deal breaker.
It would be nice to be able to communicate back to the user that some action is in progress (I think AJAX would be one way to go?)
Questions
The only thing that's not entirely clear to me is the implementation of step № 3. I'd like to hear possible implementation ideas (on Windows or Linux) as to how this should be done. Hopefully some of you can share how this sort of thing is done in the real world.
Miscellaneous
As always, if there's a problem with my thinking, please point it out!
There are many people better qualified to help with step 3 so I'll leave that to them.
My question is whether is you are looking forward to learning the mess of web technologies required for the front end or consider it a necessary evil on the way to what you really want to accomplish? If the latter (and assuming you are working in C/C++) consider taking a look at WT. It's a toolkit that makes the developing the web interface seem more like a desktop gui while handling much of the ugliness for you. It could potentially cut a lot of time off your development.
Is it worth to try to keep your GUI within the system looks ?
Every major program have their own anyways...
(visual studio, iexplorer, firefox, symantec utilities, adobe ...)
Or just the frame and dialogs should be left in the system look 'n feel range ?
update:
One easy exemple, if you want to add a close button to your tab, usually you make it against your current desktop theme. But if the user has a different theme, your close button is out of place, it doesn't fit the system look anymore.
I played with the uxtheme api, but there is nothing much you can do, and some themes i've seen are incomplete sets.
So to address this issue, the best way i see, is to do like visual studio/firefox/chrome roolup your own tab control with your theme...
I think, that unless your program becomes a very major part of the users life, you should strive to minimize "surprises" and maximimze recognizability (is that even a word?).
So, if you are making something that is used by 1.000 people for 10 minutes a day, go with system looks, and mechanisms.
If, on the other hand, you are making something that 100 people are using for 6 hours a day, I would start exploring what UI improvements and shortcuts I could cram in to make those 6 hours easier to deal with.
Notice however, that UI fixes must not come at the expense of performance. This is almost always the case in the beginning when someone thinks that simply overriding the OnPaint event in .Net will be sufficient.
Before you know it you are once again intercepting NC_PAINT and NC_BACKGROUNDERASE and all those little tricks to make it go as fast as the built-in controls.
I tend to agree with others here- especially Soraz and Smaci.
One thing I'll add, though. If you do feel that the OS L&F is too constraining, and you have good grounds for going beyond it, I'd strive to follow the priciple of "Pacing and leading" (which I'm borrowing here from an NLP context).
The idea is that you still want to capitalise as much as possible on your intended audidences familiarity with the host OS (there will be rare exceptions to this, as Smaci has already covered). So you use as much as possible of the "standard" controls and behaviours (this is the "pacing") - but extend it where necessary in ways that still "fit in" as much as possible (leading).
You've already mentioned some good examples of this principle at work - Visual Studio, even Office to some extend (Office is "special" as new UI styles that cut their teeth here often find their way back into future OS versions - or de-facto standards).
I'm bringing this up to contrast the type of apps that just "do it their way" - usually because they've been ported from another platform, or have been written to be cross-platform in GUI as well as core. Java apps often fall into this category, but they're not the only ones. It's not as bad as it used to be, but even today most pro audio apps have mongrel UIs, showing their lineage as they have been ported from one platform to another through the years. While there might be good business reasons for these examples, it remains that their UIs tend to suck and going this route should be avoided if in any way possible!
The overriding principle is still to follow the path of least surprise, and take account of your user's familiarity with the OS, and ratio of their time using your app to others on the OS.
Yes, if only because it enables the OS to use any accessability features that are built in like text-to-speech. There is nothing more annoying for someone who needs accessability features to have yet another UI that breaks all the tools they are used to.
I'd say it depends on the users, the application and the platform. The interface should be intuitive to the users, which is only the same as following system UI standards if they are appropriate for those users. For example, in the past I have been involved in developing hand held systems for dairy and bread delivery on Windows CE hand helds. The users in this case typically were not computer literate, and had a weak educational backround. The user interface focussed on ease of use through simple language and was modelled on a pre-existing paper form system. It made no attempt to follow the Windows look and feel as this would not have been appropriate.
Currently, I develop very graphical software for a user group that is typically 3rd level educated and very computer literate. The expectation here is that the software will adhere to and extend the Windows look and feel.
Software should be easy and intuitive where possible, and how to achieve this is entirely context dependent.
I'd like to reply with another question (Not really Stackoverflow protocol, but I think that, in this case, it's justified)
The question is 'Is it worth breaking the OS look and feel?'
In other words,
Do you have justification for doing so? (In order to present data in some way that's not possible within normal L&F)
What do you gain from doing so? (Improvinging usability?)
What do you lose from doing so? (Intuitiveness & familiarity?)
Don't simply do it 'To be different'
It depends on how wide you would define system look'n feel... But in general, you should keep it.
Do not surprise the user with differentiating from what he is used to. That's one of the reasons why we call him user ;-)
Firefox and Adobe products usually don't because they are targeting several plattforms which all have their own L&F. But Visual Studio keeps the typical Windows L&F. And, as long as you are developing only for Windows, so should you.
Apart from the fact that there is no well-defined look-n-feel on Windows, you should always try to follow the host platform native L&F. Note however that look-n-feel is just as much about how a program behaves as how it looks. Programs which behave in a counter-intuitive way is just as annoying as programs sporting their own ugly widgets.
Fraps is a good example (IMHO) of a program which is actually very useful, but breaks several user interface guidelines and looks really ugly.
If you're developing for Apple's Mac OS X or Microsoft Windows, the vendors supply interface guidelines which should be followed for any application to be "native".
See Are there any standards to follow in determining where to place menu items? for more information.
If you are on (or develop for) a Mac, then definitely YES!
And this should be true for Windows also.
In general, yes. But there's the occassional program that does well despite being not formatted for all the OSes it runs on. For example, emacs runs pretty much contrary to every interface guideline on OS X or Windows (and probably even gnome/KDE) and it's not going away any time soon.
I strongly recommend making your application look native.
A common mistake that developers who are porting an application to a new platform seem to make is that the new application should look-and-feel like it does on the old platform.
No, the new application should look-and-feel like all the other application that the user is used to on the new platform.
Otherwise, you get abominations like iTunes on Windows. The same UI design may be exactly right on one platform and very wrong on the next.
You will find that your users may not be able to pin-point why they dislike your application, but they just feel it hard to use.
Yes, there are valid exceptions, but they are rare (and sure enough, they tend to be the major applications like Office and Firefox, rather than the little ones). If you are unsure enough to have to ask on StackOverflow, your application isn't one of them.
We've got products built both with GUI and CHUI. Going forward, we're looking at redesigning a lot of our software and mainly taking the route of going all GUI. My question to the group is, do we need to account for keeping a CHUI around? What are the advantages of CHUI over GUI? Many times in the past people have said that CHUI is faster because you don't need a mouse. I argue that GUI can be just as fast with the right keyboard shortcuts, hotkeys and/or touch screens.
Is CHUI something we should no longer consider if hardware no longer provides a constraint?
Also to clarify, when I speak about CHUI I mean a CHaracter based User Interface, and I'm also mainly concerned with the effective presentation of data to an end user.
There have been some fantastic responses that have highlighted the importance of having a command line based interface for automation and scripting based tasks which I will certainly take to heart when we begin the design!
The primary benefits of a CHUI (that is something with forms and fields, not necessarily command line interfaces) is the keyboard for navigation and consistent layout. That is key.
If your GUI can be completely, and efficiently, keyboard navigated, then your CHUI user base should be happy. This is because in time, the users simply "type" their commands in to the system without "seeing the interface". They don't need to "discover" the interface, which is a primary feature of the GUI.
While CHUIs appear to be dinosaurs, they are still functional and usable. Most folks once they're trained (notably POS/Counter workers, but even back office scenarios like factory or warehouse floor, etc) have no problem using a CHUI.
But the key is the keyboard support so the user don't have to wait for the screen to catch up with them. Seeing a skilled operator with a mastery of the keyboard can make an application fly. You barely have a chance to see popup windows and what not.
You should poll your customers, not programmers. If your customers, who use your applications, want a CHUI, even if all your developers think it's a waste of time, you build it, because the customer is always right (except for when they're wrong).
You should absolutely still consider it. Most importantly, command line programs can be automated (and chained together in scripts) much more easily than GUIs (typically). I can't imagine working with a source control tool which didn't have a command line interface - although obviously having a GUI is useful too.
Now whether you need a command line version for your particular app is hard to say without knowing what your app does. Do you need automation and scripting? Might someone want to VPN in and run it from a very bad connection, and thus appreciate low bandwidth?
Note that MS certainly doesn't believe the command line is dead - or they wouldn't have created PowerShell.
I agree with Eli that your customers should have final say, but if you can keep the meat of your program from being too interwoven with the GUI(or CHUI), then production cost to make both available should be minimal.
If you write apps for unix and you need to handle users who telnet / ssh to your box then you will need command line interfaces.
I would say it depends on your target. Do you script your code from other apps? That would be a requirement to keep the interactive version (or some piece to avoid the GUI startup).
We usually do one or the other. But sometimes we have utils that have to be deployable through ftp and run ssh. Or we have tools that our users embed into their apps and don't want to expose a UI (data migration / conversion).
To this day, some of the most efficient user interfaces I've ever seen were plain old terminal-based character interfaces.
Anecdote: I was once part of a project to "modernize" a terminal application used by 500 customer service representatives. We published sexy GUI mockups and everyone, including the users, were suitably impressed. We worked for six months on the application, and all the user acceptance testing seemed to indicate we had a winner.
But when the application was finally launched, it failed miserably. As it turns out, CSRs are measured for performance daily, right down to the average number of seconds per call handled. And no matter how hard they tried, they could not match the same level of efficiency in the GUI as they could in the terminal interface. They could get close with tabs and shortcuts, but not quite there.
Hard lessons learned. Modern programmers may abhor "dinosaurs", but do users really care about slick interfaces? Usually they just want to get their work done.
When I first read this, my immediate thought was that this is probably one of those apps that's basically a series of forms, but displays inside a terminal. Often you see such dinosaurs running on cash registers. I also recall seeing such an app used to apply for a loan when I bought my car. This type of application doesn't seem to have a place in the modern world -- any system with even a tiny bit of processing power can handle a normal GUI nowadays. Unless you're trying to support really low-end legacy customers, get rid of this user interface. A GUI with decent keyboard shortcuts (please, please, please put some thought into keyboard-only use of your GUI programs...) is going to be equally effective for the users coming from the old CHUI system and much friendlier to those used to a GUI, without having to have 2 versions of your app.
I don't see why everyone is bringing up command line apps. I think most people recognize that the command line isn't going away. It's far faster for many tasks than a GUI, largely because the programs tend to be non-interactive (and thus easily scriptable). As soon as your app becomes interactive (or, at least, doesn't have a param to make it non-interactive), running it from the command line is much less important. Even awesome programs like Vim that are terminal-based are transitioning to their graphical counterparts (gVim) because it gives you the best of both worlds.
Even GUI apps like Firefox can benefit from command line interfaces like Ubiquity. If there's a way to provide the command line from within the GUI then why not have the best of both worlds?
A lot of CAD programs have command line interfaces that show you what the GUI interaction you just performed equates to in the command line. That way you can learn the command line operations for the things that you do frequently and where the command line can be quicker to interact with whist still having the discoverability of the GUI interface.
See this youtube video demonstrating Rhino3D's command line
CHUI is faster in execution speed, not user interaction speed. I write embedded systems (as well as GUIs), so I'll always have a use for command line apps.
Every study I have ever read showed that CHUI's are much faster for experienced users. GUI's are easier for new users and for applications that are only occasionally used. Also for a given screen size, you can display more information on a CHUI then a GUI. A good GUI can give you a quick over view at a glance.
In addition to the other benefits mentioned above, I've frequently found another reason to keep around an alternative UI--it keeps you and your interfaces honest. When an application is built with only one user interface, it becomes much easier to let design principles slide and for your business logic, etc. and your GUI to become an intertwined ball of spaghetti--despite best intentions. Regardless of the importance of your customers having a command-line interface, soon there might come a time when an alternative GUI (read: presentation layer) might be needed, and you'll want to be prepared. This might not be relevant to your requirements, but I think it's something good to keep in mind...
One of the big issues that we encountered was multisession capability which is almost nonexistent with the GUI technologies I have seen. Our users were quick to point out that with the current character based interface they could have over a dozen Telnet based terminal sessions going at the same time on their PC screen which enabled them to multitask or task switch with high efficiency. They rated multitasking as the killer feature which they benefitted from in our fast paced environment where interruptions are frequent. Being able to have concurrent access to multiple instances of a particular ERP application or multiple different ERP applications while always retaining session states was important to our user community.
I think the problem comes from design practices in GUI forms. We tend to place more objects on them especially with a vertical scroll bar and tab capabilities. This also makes loading slower. Going through CHUI menus with the keyboard is faster once you've memorized those sequences and holding the Ctrl key isn't required. There is something about the menu bar in Windows where the short-cut key descriptions are off to the right. The character based menus seemed easier to remember after awhile.
A) - This Menu
B) - That Menu
C) - Some other Menu
Or you could arrow through the choices and you just seemed to have some muscle memory where That Menu is the second choice.
As soon as you present some data, someone's going to want to query against it. You can integrate that with a gui, no problem. If you think some of your customers are going to want to script certain tasks. set it up. Anything to do with automation is better done from the command line(y harlo thar cron job!)
I love guis. I'm a mac user. But there is a time and a place for a CLI.
I was sysadmin at a university math department when the registration system went from a character based system using telnet, to a gui system on a PeopleSoft app.
The gals in the front office HATED the new system. Now part of this was the whole bit about old shoes being more comfortable. But when I asked about it, Christine said that even after a week of doing several hundred registrations per day, the new system took several times as long to do anything. Lots of things only doable with a mouse. The old system could accept input as fast as they could type. Screen repaints were under a tenth of a second. New system had lots of 3/4 to 2 second pauses -- just long enough to be annoying, not long enough to do anything else.