Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 1 year ago.
Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.
I've been thinking about the on going "revolution" in UI design and metaphors for interacting with the computer via a GUI and I'm suprised that as long as computers have been accessible through GUI's that programmers are still searching for the best way to allow the user to interact with their programs. It seems that most of the work centers around astetics(which I understand are important) but I don't understand why we are still looking for the magic bullet in UI design.
My question is: Why is UI design and components not a solved problem with accepted and understood approaches?
Probably because like most things, design (and tech, in general) are constantly changing, being worked on and revised. To say that one of the most crucial elements in software can be 'solved' would be an understatement and would be constantly changed again. There is no true definition to the 'perfect' GUI, only because you don't know who your users will be (power users versus casual, more input required vs less).
perfection is a moving target
Jacob Nielsen rightfully said about ten years ago that users don't scroll. This isn't true anymore.
Users get trained to user interfaces. Windows 7 doesn't show a system menu icon in the top left corner for many apps (e.g. in explorer), but you can still go there and invoke the system menu. Took me a while to notice the icon was missing for some apps - while using it.
(There are probably much better examples.)
The optimum isn't obvious. Consistency is core in UI, but only deviation from consistency can lead to improvements. You just can't optimize for "most consistent" or "most creative", both will fail.
it's a cross-domain skill. How many people are programmers, designers and neuroscientists? How many CS university courses teach cognitive models and how they apply to user interfaces? How many programmers pondered muscle memory, feedback loops and cognitive load?
UI's are still designed largely by programmers and sometimes fixed by designers after the fact.
effect is hard to measure
Take the Microsoft Office Ribbon: Judging from the responses, it seems to work better for many, yet is harder by orders of magnitude for others. It was a bold step, no doubt, but was it good? Microsoft does run UI tests, and they did it for the ribbons - whether they screwed up the tests, whether office politics won over facts, or wether the backslash was just wasn't forseeable in the data, I don't know. (But I'd seriously like to)
How many shops can afford user tests? Everyone can do hallway usability, but that just ensures you don't suck.
Skimming along the line
There is low pressure for the perfect UI, there is high pressure for a good enough UI. Given the lack of common knowledge and the high cost of improvement, perfect would not be affordable. The "Apple tradeoff" involves a higher price and technical shortcomings. They are pushing the limits (good!) with bold steps (very good!), which captures a notable but not major market segment. Still they are far from perfect.
I think if you ask Henry Ford the same question about designing automobiles you would have gotten an answer that would equally apply to your question today.
And that answer is, we're still in the infancy of human computer interaction design and we don't yet have enough data to design genuinely ideal systems. And, even if we did we don't yet have the ability to manufacture such an ideal system at an affordable price point.
Much like Henry Ford could not have designed the Bugatti Veryon in his day, nor could he have built it if he could design it. Or the Prius for that matter.
No, User interfaces isn't that subjective. Ergonomical matter is a scientific topic.
Think about that :
Today, everybody uses a computer. That was not the case 30 years ago.
Today , everybody uses a glass surface to access data. That was not the case 30 years ago.
Today, you've got several devices to access your data. That was not the case 30 years ago.
Today, data is collected everywhere. That was not the case 30 years ago.
Today, you can even control your data with glasses. That was not the case 30 years ago.
There is no magic bullet. just like nature, we're talking about an evolutive and living ecosystem, in the pure darwinian way.
UI design is to make people who have less knowledge about it but can easily understand the application and use it comfortable. That is core challenge of the UI design. So it evolves just like a robot. There is no end to perfect design. As along it makes the users to use easily then it is a perfect design.
User Interface is a very subjective subject, what might be ideal (graphically pleasing, efficient) for one person or task might not be ideal for another task or even another person doing the same task.
Also, the different platforms on which GUIs are implemented is ever changing and thus needing GUIs to evolve to meet specific platform demands (touch screens, ie. lend themselves towards a completely different user interface, then a mouse based platform, or even something like an ATM)
However, there are classes and books written on the subject, so there is some level of continuity in the area that has been there for quite some time.
User Interface is a very subjective subject, what might be ideal (graphically pleasing, efficient) for one person or task might not be ideal for another task or even another person doing the same task.
Also, the different platforms on which GUIs are implemented is ever changing and thus needing GUIs to evolve to meet specific platform demands (touch screens, ie. lend themselves towards a completely different user interface, than a mouse based platform, or even something like an ATM)
However, there are classes and books written on the subject, so there is some level of continuity in the area that has been there for quite some time.
In short, TECHNOLOGY.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I recently got promoted to be the Project Manager/Supervisor. What do you think the leadership style a managerial role in Programming Dev't should have?
What's your style?
Hands-off, servant leadership, unofficial or "tribal" leadership over traditional management, seem to be all the rage these days.
Basically getting out of the way and allowing the team to get their job done seems to make sense to me, but it all depends on the culture.
I would say an effective manager would already have a style, and know how he wants to work, whereas a less effective manager would probably learn from other senior managers and simply emulate "however things get done around here". Actually in a lot of places the latter is the only choice.
If you have the freedom to do things the way you want, I would probably prefer to borrow ideas from the agile/lean camp than the more traditional PMI/Prince2/PMBOK camp, but it all depends really.
The job of a manager is to get out of the way and let the developers do their jobs. If they encounter an obstacle it is your task to remove the obstacle.
I do not believe to simple management guidelines. In an ideal world, the job of a software manager would be to just provide food, computers, electricity and salaries, but we are hardly in an ideal world.
In a way, being a manager is a highway to frustration. There are few opportunities for a direct contribution to the project, you spend most of the time on planning, meetings, writing reports, and proposing future projects. In a nutshell, you have the responsibilities, while they have the joy of building things. In order to avoid quitting the job due to lack of fun, one needs to find a proper motivation which would justify the troubles.
Now, different people are motivated by different things. Some people like to participate in group efforts, some like the achievement in building things which can't be built by a lone enterpreneur, some like the power, some like the money. I think that a management style should be tailored to the intrinsic motivations of all of the involved parties. For example, it is useless to try to motivate your coworkers with money if they are primarily interested in building cool things (and vice versa).
A key competence in managing people is being able to address conflicts as early as possible. The conflicts range from trivial (X keeps committing buggy code to the repository) to critical (we need to hurry up in order to hit a deadline). I think it is very important to be able to express such concerns frankly and clearly, regardless of the managements style. Thus, at the end of day, oral communication capacities would be at least equally important as the management style.
I dont think it matters alot what style you choose. When leadership is "broken" it usualy is due to more basic things not done right.
Consistency: stick to your style unless you are sure it doesnt work out.
Honesty: Might seem obvious but when "fooling arround" too much with carrot and stick it can get out of control
Respect: Tech-Guys have all different characters but grasping what they value is easy - being passionate about technology and using it in professional way will open hearts. Waveing about your iphone showing off fancy looking but technologicaly trivial apps might result in the opposite ;)
Lead by example: You techs do extra hours? You do extra hours too!
Motivation: You dont need a jungle camp every 3 weeks but you can still help everyone to feel better about seeing each other more often than the family. Implement a friday afternoon beer-session if that is acceptable (be strickt about times though, no drinking before 6pm for exmaple). Show interest in what people are working on even if you are not part of operations. When working on abstract subjects people can have a hard time to put into relation what value they add to the company and to the team. When "in the jum" programmers particularily can become like lone astronauts - Having a broader understanding about your business you will need to remind people about the mission (though thats PM tasks mostly, but no PM is perfect too)).
In the end you are good leader when your team says "WE did it!"
There are plenty of methods with catchy names, but in general I prefer the management style to be lightweight and encourage communication.
I suspect a lot of us have had the experience of having to spend more time filling out forms than actually developing. Than is both frustrating and unnecessary. Controls are important, but a new form is not the solution to every managerial problem.
As far as communication goes, many managers seem to believe that it will work if everyone reports up to them and then they send the collected information back down. That can really lead to disaster. The team needs to communicate with each other well and often.
Finally, I'd like to throw in that as tempting as it is to take a new resource for a project and get them developing as quick as possible, I think it will always work out better in the long run to hold off and get them properly trained and oriented to the project.
My style is a combination of Attilla the Hun, Napoleon Bonaparte and Nelson Mandela. Whatever you do, don't try to adopt my style.
More seriously, to be a good leader you have to develop your own style and you have to integrate that into the culture of the organisation you work in. So, the answer to your question must start with asking yourself some penetrating questions and giving honest answers to them. You must also take some time to understand the traits of the individuals in your team and figure out what makes them tick and how to motivate them as individuals. What works with one may not work with another.
And, while I'm writing, I'll direct a passing kick at the respondents who suggest that it is a manager's job to get out of the way and let the team work: it's the manager's job to manage, you have people you work for who have certain expectations of you and you have to pay attention to them as well as to the losers on your team.
I write 'losers' because you have just been promoted and they haven't. Sure, you have to lead them to great achievement but you won't do that by keeping out of their way, you'll do it by leading them in the right direction, with the right mix of carrot and stick. Oh, and don't let them know that you think they are losers, it will upset them.
First of all; if you try to adopt a "style" that's not your own, you will most likely fail. You basically just have to be yourself! (That's probably why you got promoted in the first place) That said, there are some theorems to embrace, one beeing "you can always be a better leader" ;) I guess that's part of why you posted this question. My advise is to support your co-workers, and remember that it's your job to make them as good as possible. Try to keep yourself on top of all that happens within the project and encourage communication within the team. Agile style development helps with that. Also, try to put yourself in your co-workers shoes and try to imagine what they expect and want from you. Best of luck
There is no one "style" that you can or indeed should focus on. The reality is that you are now a people manager and people are all different. You need to learn to recognize the differences in the people you are managing and respond accordingly. This is a technical role, so if you have some technical understanding then this will assist with gaining respect of the team.
Some people need to be told what/how, some people need a gentle prod and some need full ownership of a task. Learning to spot the differences is where you need to apply yourself.
Typically people fall into 4 distinct camps with different names depending on the management course of the day :)
Beginner, highly motivated, not much experience, needs a more directive approach
Learner, more capable, but may be experiencing frustration, needs coaching
Performer, very capable but may lack confidence, needs supporting in their approach
Achiever, capable and committed, needs delegation of tasks
Management 3.0 Leading Agile Developers, Developing Agile Leaders by Jurgen is a book dedicated to answering this questions. http://www.management30.com/. His home page is here http://www.jurgenappelo.com/
In his book and class, he refers to Martie, the Management 3.0 model. It is composed of
Energize People
Empower Teams
Align Constraints
Develop Competence
Grow Structure
Improve Everything
An excellent introductory presentation can be found here: http://www.slideshare.net/jurgenappelo/what-is-agile-management
Jurgen's two key takeaways.
A software team is a self-organizing system. Support it, don't obstruct it.
Agile managers work the system around the team, not the people in the team.
Enjoy.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I have worked on a few multi-cultural projects (programming languages are universal, social norms and mores are not) and it's always interesting to see how the team dynamic works cross culturally. I'm not talking about coding differences, I'm talking about basic ground rules for communicating cross culturally at the start of the project. Good team building exercises, using small teams vs large teams, isolating functionality to make all developers feel as if they are contributing, fostering respect, and etc.
In our increasingly multi-cultural industry, what works and what has failed?
I looked into this in some detail a few years ago and came to the following conclusions (in no particular order):
The outsourcing organisations we looked at (all Indian) had a very strong process base. I don't know if this was cultural or just the way they chose to set themselves up (possibly a bit of both) but we felt this was likely to be a real issue.
They were talking about being a five on the Carnegie Melon Maturity Model (Google it but basically that means they've defined and documented everything up to and including what happens when someone farts), we were typically running around a 1 or a 2 (roughly equating to crossing your fingers and hoping for the best).
Our process level was largely driven by our clients who didn't have any interest in signing off specifications (for good reasons and bad), wanted people who understood their business and would fill in the gaps, and wanted to change their minds three times a day. As much as many of these factors infuriated the programmers in the UK we understood that they were never going to change.
This was possibly our biggest concern - we didn't feel we could come up with a process model that would work for all three groups involved (the clients, the UK based IT team and the Indian based outsource team).
So first thing is - work out what your process is and work out whether you honestly think you can make it work for all parties involved. It's easy to say "we're going to do agile" but how are you going to get that to work when one party is 1000 miles away? Alternatively if you want to go a solid waterfall route, is that realistic given your clients?
Second, understand the ingrained cultural differences within your teams.
My experience (and I obviously generalise here) is that programmers from the US and the UK willingly (sometimes too willingly) question authority and assumptions. Ask them to do something dumb and you're likely to find yourself being told that you've asked them to do something dumb in no uncertain terms and they'll then proceed to tell you what you really want.
That's not the norm globally. Many Indian developers I've worked with don't question things in the same way. That's not to say they aren't as bright, they just apply their intelligence to delivering what you've asked for, assuming that you had a good reason for doing so.
You can make a case for either of these being good / bad (I've lost count of the number of times I've heard developers question what they're told and say how things should be despite not understanding the basics of the industry they were working in), but the important thing is that they're different and they'll clash.
So the answer is likely to be that you're going to need to feel out the teams involved and, based on that, pick out ways of working that are comfortable for both of them.
Yes, get video conferencing set up, get each time to visit the other site (it makes a big difference) and where possible get people talking even when it's not strictly needed in the early stages, but most of all make the effort to understand the groups involved and design a dynamic that works for all of them - imposition of one world view on the other won't work.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
As we are a small company, I work as both a project manager and developer. The specifications I create for clients contain a number of elements used to describe and define the project, including user stories alongside any other elements I feel need to be included to define the project (e.g. wireframes, userflows, sitemaps etc.) to the client.
If a functional specification “describes how a product will work entirely from the user's perspective. It doesn't care how the thing is implemented. It talks about features.“. Then does anyone see any problem with using User Stories to define a functional specification for a website? Does anyone actually do functional specifications in this way?
Really I am trying to up my game a little, and wondering if this would approach would work for larger clients who perhaps have more stringent ideas on what a functional specification should contain, whereby a formal approach may be required. Definitely at the moment our clients respond well to our method of producing documentation.
I am interested in hearing what people who do project management professionally think about this.
I'm at odds with what a couple of other people have said.
First up the bit I agree with - stories are a great way of stating functional requirements. For my money they're one of the best ways of actually communicating requirements in a way end users will really take in. I've seen too many specs that get signed off without ever having been read.
The one thing I would say you might want to append to them is non-functional requirements - covering performance, security, data volumes, audit, archive and so on. While they can be covered in stories, sometimes they're better covered in a way that crosses all stories.
In terms of whether it's suitable for large companies this is where I disagree. In my experience (and I've done projects for Shell, American Express, a couple of multi-national banks and others) they're often no more formal than smaller companies so they'll be fine with stories. The reality is that a user in a large company is no better equiped (or interested) in reading class and sequence diagrams than they are elsewhere.
The size and complexity of the project may require more detailed requirements but it's the size of the project, not the size of the company that matters when you're determining how you document requirements.
For me the best requirements documentation is documentation that's suited to it's audience, and for me user stories hit the nail on the head most of the time - they're short enough and clear enough that when they sign them off they mean something because they've read and understood them (as opposed to the sign off of a 100 page spec which invariably means they haven't really read it), but good enough for the developers to work from too.
Yes, you can use user stories for your functional requires. I do it all the time, and have been for years. In my opinion, it works really well, and better than other systems I have used.
Would this approach work for larger clients? To make a gross generalization, no. They are going to have some system that use to define requirements, and likely its not user stories. If you come in with user stories, there is going to be a disconnect with the current practices, which you will have to work through.
I have been successful using user stories with larger organizations, but it take a concerted effort, which both parties need to be committed to.
What you're describing are the use-case scenarios that define the features, this is what is required from a usability perspective and is exactly what the client will understand and agree to. Screen mockups and flow diagrams will definately help both the client and developers.
An implementation specification may then be required to instruct developers on what needs to be included in the actual construction, the depth of this will be determined by your developers capabilities that include their knowledge of the house architecture/framework and methodologies/conventions and may include specifics on what impacts various parts of the application.
We also work in small teams (sometimes one or two developers) and believe the above is all that's required in this instance.
Larger companies with much larger teams may use Modeling Software, UML diagrams and other more detailed specifications. In the case where you the primary developer, you should still spend the time designing your application, but if nobody is going to review the designs and insist on all the formalities, your time is better spend implementing the software.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
Based on what criteria they choose the projects and what are the things based on which they choose a project...?
Return on investment, if they want to stay in business.
Return on investment is ofcourse the final product. But it takes a number of factors to get there:
Their own expertise: Do we have people with skills needed to do this? Can we hire some?
Available resources: Programmers, Managers, Hardware, Time, Financial resources.
PR: Even if we dont get paid that much, will this project get us more business?
PR: Pay is great, but do we really want to be associated with this client?
Their Mission/Goals: What fields/niche do they want to compete in. Do they want to expand?
Past experiences: We did a project like this, it was horrible. Lets not do that again.
Past experiences: It was fun last time, AND we can reuse half the code! Lets do it!
Usually the management uses more sophisticated matrices and all to make their decision, but more or less, these are the factors they usually put in.
I am sure someone can provide a more specific/scientific answer.
Good question. The straightforward answer may seem to be Return on Investment (ROI). However, ROI is criticised for three reasons:
Short-termism: ROI is seldom calculated beyond 5-7 years (due to increasing discount rate on any cash flows produced in the future), some projects really worth doing realise full benefits much further in the future.
It’s hard or impossible to put monetary value on some things. The often cited example is human life. The other is moral principles. However, most frequently encountered thing in software world what is very hard to put a price on is opportunities that will never emerge unless this project goes live. It’s hard to put a value on the emerging opportunities, because we don’t know what they are until they actually emerge. And I don't mean opportunities that will simply not “open”, but specifically emerge.
ROI doesn’t take into account wider strategy. The importance of strategy in software world should not be underestimated and the strategy should take into the account specifics of providing software products or services. Geoffrey Moore’s “Crossing the Chasm” is a brilliant book I recommend and is very pertinent to the software world.
Joel’s recent instalment “Fruity treats, customization, and supersonics: FogBugz 7 is here” has a great sample of strategy document and the reasoning behind it. It seems that FogCreek plans to leave the bawling valley and enter the tornado (according to Geoffrey Moore’s classification) with their FogBugz 7.0 and hence the strategy of removing barriers that prevent people from switching to FogBugz, instead of spending time to introduce some more vertical features.
Other tools that can be used for selecting projects are SWOT analysis, Pareto analysis (i.e. choosing a project to address 20% of causes that are responsible for 80% of problems), PESTLE, Cost-Benefit analysis (similar to ROI, including the critique).
However, it seems that a sane strategy that states that the company is planning to do and not be doing in the finite period of time (often next year or two, in high tech market conditions are hard to predict beyond that horizon), gives a simple guidelines for choosing priorities and clear direction for joint efforts is the best starting point.
I also recommend reading a fabulous book “Almost Perfect” by Pete Peterson (former CEO of the maker of WordPerfect) that is available online. The book tells a real-life story of different strategies SSI Inc followed, some planned and stated and some ad hoc, and the way they were used to select what to work on.
ROI is only one measure. There are many other factors:
Risk management - for example, improving the process may not show any direct return on investment, but by adding e.g. unit tests the quality of the software can be improved and risk of a production bug reduced.
Compliance - there may be requirements by industry or government that need to be followed. Directly this may not show a return on investment because they may never be audited, but the downside to being non-compliant is huge (being shut down).
Manageability - providing metrics on bugs, project schedules etc. may not show a direct return on investment but it may allow them to better predict and manage their projects.
Security - this may be considered as a part of risk management, but it is a broad enough area to merit its own category. Making legacy code secure can cost a large amount of money and not show any immediate return, but there are obvious reasons why this is worthwhile.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
From time to time, there will be student attached to our projects, i would certainly like to assign him/her many things to do so can learn more. But alot of times we are resigned to assigning stuff like documentaiton, updating of ui mockup screens etc. As problem is that is it bit hard to trust the quality of work provided by students and another thing is that they are still young and their enthusiam may not be there.
How do we better utilize them such that they really cut down our workload and also in turns mean learning more stuff which will aid them in their future job opportunies?
I am afraid it might sound disappointing but it is not the best idea to utilise students to cut your organisational unit workload down. Probably, if your goal is cutting workload the best thing is not to take students. Read on to understand why.
Though you haven't specified the level of work-related expertise the students possess, nor did you mention the duration of their attachment, I assume from the tone of your question that their expertise is not sufficient to hit the ground running. It is also reasonable to assume that they are not staying for longer than 2-3 months.
The essential benefits your organisation can extract even given the limited timeframe are:
Notice and grab talented workers before they even get to the job market. Later in their working life they are likely not to be that easily available.
Turn every student into your organisation salesman. Let them tell everyone how good your product is, bring you in contracts in the future or make their peers envy their work experience increasing the pool of good candidates for your company.
Outsiders can help cast a fresh eye on your processes, procedures, product, expose inefficiencies etc.
Learn from them the latest stuff taught at universities.
Boost your time morale: Maslow theory, "esteem needs". Even the most junior member of your team becomes somewhat more senior, since these students have yet to achieve that position.
Cutting down workload means that you'd need to find a set of tasks which is fairly independent, does not require knowledge or skills that the students do not have and needs much of your team's time to transfer. The tasks cannot be strategically important in case they cock it up, not can it be operationally important. Hence you left with some dusty requests for management reports or research and development projects.
Chances are that R&D considered to be more desired work within your organisation and if you give exclusively to students some people feelings are going to get hurt.
How long are the students around for? When we have had students on-site for up to two weeks there was not much other then testing type work we could give them.
If the student has enthusiasm you code do some pair programming through a bug and let them write the unit tests for verifying the fix.
Even if you don't normally do pair programming, I find that with a junior dev it is sometimes productive to have him/her do pair programming with a more experienced developer, for the following reasons:
I wouldn't assign coding tasks to the junior developer alone, because his code would have to be closely reviewed by someone else anyway and quite probably rewritten or changed substantially.
On the other side, how can a junior developer learn if not by programming? So, you want him participating in some way in programming tasks.
You get some of the advantages of pair programming: the most experienced dev is less prone to make silly mistakes (even a very junior programmer can point things like 'hey, you made a typo there') and less likely to goof off checking stackoverflow.com every 10 minutes during the pair programming session.
Of course I also would rotate the junior with several seniors during the day, so they don't feel 'slowed down' or annoyed by the young guy for extended periods of time.
Why not assign one or more engineers as "sheperds" to the student and let them oversee their work or even better pair with them. The student will gain a good understanding of your project and real work and have a known fallback when in trouble and someone who can give provide direction.
The sheperd/mentor gains a fresh perspective, and the joy of teaching.