Recently in our team we had a discussion about whether to have colors in API responses. For example
{
"message": "Hello",
"color": "red"
}
versus
{
"message": "Hello",
"type": "danger"
}
For the first option pros are
If you need to change color of some element, you don't have to re-compile and submit again your app to AppStore
Cons are
You cannot push all colors to the API, some of them still will be hardcoded.
If you change one color, you will have to change all other similar colors, otherwise you are at risk of having Christmas-tree app, with bunch of slightly different red colors.
For the second option pros are
You have purely information based API, you decide yourself how your ui should looks like
cons are
If you need to change some color, you need to re-compile your app and publish it again to AppStore, which sometimes may take a while
Dear friends, what do you think about those two different approaches? Please give some arguments to either prove my opinion or dodge it. How other big companies design their APIs? I never seen API providing colors, however I haven't seen a lot of APIs.
Thank you very much
An API is designed to provide a way to access pure data, without any UI content, therefore, second option is more "correct", becouse it only specify type and not how it should look. With this option, anything could consume your API and decide how every message type should look.
As Miller explained, API should be independent from UI part means you should always fetch data from API to UI and then take decision from UI module what to do with that.
I think you are not going to change color for any message that frequently like danger is always RED and good is always GREEN.
So don't worry about re-compile other stuff. Most of the cases, you are going to add color instead of change.
If you still want to discuss more then please explain your use case and application in details.
Related
I absolutely love react-leaflet! I'm using it to produce basemaps for weather alerts on a next.js driven site. My company requires that the server is on the Intranet only. Therefore, for employees outside of the company, I'm sending an e-mail for specific alerts and would like to include a PNG attached image of the map with the alert features. I've dived into leaflet.print and leaflet.image but all seem to require human interaction to press a button in order to save the image. I'd like this done automatically when the alerts are e-mailed to the recipients. I understand that having a View/DOM (Browser) might be necessary. However, for automation reasons, I'd probably want this to happen on the backend (node.js). Is there anything out there that could possibly do what I'm looking for or, is the need for a DOM/View going to make it difficult or impossible? Thanks in advance. I usually try to research as much as I can before asking a potentially repetitive question, but I'm stuck here
I'm working on an a pretty big project right now and am trying to implement an MVP architecture. I'm starting to run across a instances where I think JQuery or Javascript might be better suited than server-side code. I'm looking for feedback on how others are implementing client-side programming into their enterprise applications. How are you structuring the client-side code and how do you determine when to use it?
Things that can make user say "wow". For example - Populating search results while user has just typed 3-4 character of search term. Just go back in past and think about Yahoo or Hotmail which used to postback to server when you clicked on "Create Message". But when google came they just did on client side without going to server. I bet you would have said "wow" to that. At least I did.
Things that can reduce server load. For example - Adding extra data entry row in HTML table, instead of doing it through round trip, Increase/Decrease of quantity etc.
These are just some example to sight. Even to do these things properly you need to go to server but that will be behind the scene using ajax. Other than this you need to select few more jquery plugins that you will use in your project. To name some are jQuery UI, jQuery Validation, jQuery AnythingSlider etc. There are too many of them.
Http://ClearTrip.com is one site that I envy for their UX. Visit their site from mobile device and you will get further clues about their UX work. Besideds just coding you need to have a person in your team who can work on these UX aspects.
Regarding how this fits into DDD: I've just recently started my journey into DDD but one hears a lot about command/query separation in that circle. Certainly if you are doing something that hits your domain (like fetching for auto-completion or certainly if you allow partial page submission to accomplish a domain command) you have to decide how it gets there and how the domain is structured to handle it.
I think two decisions are most relevant.
First, bits entirely in the browser and even those specifically in your application layer are outside your domain and thus, though covered in the layered architecture part of the DDD discussion, do not land in the entity/value/event/service, etc. discussion. If, however, you are using AJAX to interact with your application layer and in turn need to access your domain, you need to consider again two things in my mind.
(a) Are you separating commands and queries simply using different methods on your domain? Fine if you have a relatively small demand for either queries or commands and this will not seem like "noise" in your domain API. Otherwise, you have a separate bounded context...another domain modeled just for queries that your UI needs to avoid clutter on your domain. Regardless, you are doing something like JS->AJAX handler in application layer->domain (including a domain service).
(b) Is this a command or a query? Once you have (a) figured out, this lets you know where the access will land...then use the presentation layer's use case to elaborate the domain concept and put it into your ubiquitous language.
Second, you have the DTO vs direct to domain decision. This can be a religious war gathering topic, but usually the answer is "depends." I think there are cases for using DTOs and cases for not (within the same architecture)...just search for all the discussions around the topic and apply the pattern only where it adds value; I won't try to cover details here.
Hope this provides some insight or at least conversation magnet to which others will add.
I guess this question is a little too subjective. Looks like I'm just going to grab a view books on advanced javascript and study up on the JQuery library.
this is my firts post here ever.
I have to develop an aplication for a group of people with special needs. The functionality is really trivial, however, i have no clue of how to do the interface for them to be able to use it.
Their intelectual habilities are perfect, they are actually studying high school, but one of them types with his nose which needless to say, is very dificult and another one types reaaaaaaally slowly with only one of his fingers and neither can use the mouse.
I was wondering if i could use javascript to develop a usable interface, based on huge grids or something like that or maybe you guys have a better idea.
Political incorrectness aside, why don't you ask them? You're talking about accessibility here, if they're using computers they must be able to tell you about what they like or dislike about user interfaces that they've encountered.
I'm going to split my answer into two parts - design and implementation.
From a design perspective, it's important not to be intimidated by the fact that the users use a computer in a different manner. Treat this like any other project. Observe how they currently use other apps, and ask about the kind of things that they find helpful, or have difficulty with. If they claim nothing is difficult, ask a teacher or assistant, who will be familiar with the kind of things they struggle with.
Once you've started implementation, try an idea and get initial feedback. If you simply ask how they find the prototype, they'll likely say it's ok. Instead, try observing them using it without saying anything or giving guidance. If they get stuck, let them find their own solution to the problem. If appropriate, you could ask the user to speak their thoughts out loud (e.g. "I need to save this form, so I'm scrolling to the bottom, and clicking save").
On the development side, try to use web standards (valid HTML, CSS and Javascript). People often point to the "Web Content Accessibility Guidelines 2.0" (WCAG2) but this is quite turse and hard to understand; there are many more friendly articles on "Web Accessibility".
Someone with a physical disability is likely to use an alternate input device, such as a "Switch", onscreen keyboard, head-tracking device, a device for pushing keys on the keyboard, or speech recognition. Many of these methods involve simulating the keyboard, so by far the most important thing is to consider the accessibility of your site without using a mouse. For example, try tabbing through the page to see if you can access all elements in a reasonable amount of time. Consider using the acesskey attribute to provide an easy way to jump to different parts of the page (using 0 through 9 is often recommended so you don't interfere with browser shortcuts).
Also make sure that no part of your site is time-dependant, as different users may take different amounts of time to perform a task. For example, don't use the onchange Javascript event to update a page based on a listbox selection. Ensure you have alt text for images, so it's accessible for speech recognition. make the pages short enough so that excessive scrolling isn't required, but not so short as to require following lots of links.
Those are just some ideas to get your mind going in the right direction - but there are many accessibility resources on the internet - steal freely, and don't reinvent the wheel.
I realise I haven't addressed your question about Javascript - that's because I think it's probably one of the less important considerations. If possible, use Progressive Enhancement techniques to make the site work with and without Javascript. You might also look into the WAI-Aria standard for giving semantics to your Javascript.
And finally, to reiterate my initial point - make something simple, show it to the users, tweek, and show again.
It doesn't really matter what technology you use. Use whichever suites you.
But, make sure that you make UI components BIG in size(Bigger buttons, bigger font, bold font, coloured font(are there any colour blind?). This is for the ease of use of people (you said someone types with nose).
Also, better to have audio as informative source along with the usual screen display whenever some wrong action is performed on the application. This way visually impaired people will be assisted more.
Do it well, you are doing a divine job.
The first thing that you should read up on is the Web Content Accessibility Guidelines written up by the W3C.
In a nutshell this document describes the basic principles for people with disabilities in general.
For your needs regarding persons with special needs, you might want to look at Jakob Nielsen's article on Website Usability for Children, wherein principles of web design for young children or people with otherwise limited cognitive ability are outlined.
I'm also interested in more general thoughts, but here is my specific problem. In an ASP.NET web app, I am connecting to a 3rd-party via API. The 3rd-party requires that the user login and answer a few configuration questions to set this up. All of the questions except one the user can just choose the default. On one question if the user chooses the default option, my app won't work with the 3rd-party. It is a limitation of their API. It is on their list to fix, but who knows when or if they actually will?
So what is the most effective way to give the user instructions in my app that they will follow once they go to this other site? Right now I have a screenshot with the option circled in red, follow by some descriptive text. What other techniques have you used in a similar situation?
Red text is the default mechanic in UI design to indicate importance (which is why it's used for errors so often).
Asterisks are the default choice for indicating required input.
Avoid flashing, and other garish-looking visual mechanics.
If this extends beyond a one-time inquiry, you should look at reading some good GUI books, like Don't Make Me Think: A Common Sense Approach to Web Usability and Designing Web Usability, both seminal books in the field.
I think you're headed in the right direction. I would make sure that your illustrative screenshot is large and easy to see the relevant details on. Also, some highlighted (classic yellow background ala 37 signals?) text to emphasize the importance of NOT selecting the offending option would be helpful.
Also, make this screenshot and highlighted instruction text, the VERY last thing they see before you forward them to or present the 3rd party site. Maybe make the action link (button, link, etc.) explicitly outline their acknowledgment of the thing not to do.
Maybe even, have fun with the caption like...
"I understand that choosing the default option above won't work."
Just some thoughts.
Unfortunately, nothing you can do will prevent idiots from choosing the wrong thing anyway. Basically, you can't make it idiot-proof.
This is more for GUIs but (depending on how critical this is) you can force users to type "I will choose xyz" before a redirect.
Is there a way to set a default on your end to get around this problem altogether? For example, picking some random setting initially that they could change in a profile of some kind that you can store on your end.
I've typically seen a red asterik(*) used for marking required fields on web forms if you want to not pre-select some value for the user for another way to try to solve this issue.
I know you want abstract, generalizations but there is no one true answer for what you're asking. I mean, what kind of content are we dealing with? Is the content broken up over multiple pages (or should it)? What kind of users generally use the form?
I know I've dealt with similar problems in dozens of different ways. Ideally you want not start treating your users as complete retards straight out of the box (just move to that progressively as they fail tasks), but you also want to be clear on what's going on.
The really high level (and obvious) ideal is that you want to make the instructions stand out to your punters. Colour change and standard icons do this (often poorly). However, changing the background colour of instruction text (to say a light gray) with a large icon (like a yellow sign with an exclamation mark) tends to focus the eye.
Another idea in your situation is to break the content in two. This might be done physically (press next to continue) or you might just colour code that hole part of the element a different colour to notify the user that they need to treat this differently.
When does it become unavoidable and when would you want to choose JavaScript over server side when you have a choice?
When you need to change something on your page without reloading it.
Designer perspective:
When you want to give more interactivity to your web page
When you want to load stuff without reloading (i.e.: ajax for example)
When you shouldn't use:
When You don't want to spend 1000 hours in pointless tries to disable the back arrow of your browser :)
Google maps would not have been possible without JavaScript. At least not in the form we know (and love) it today. So, depending on your ambition (and requirements) clearly: sometimes JavaScript is unavoidable, even though there exist technologies that take another approach that might have worked equally well (Java Applets, RIA technologies, etc).
If I had the choice I would probably chose JavaScript over a server-side implementation for a large number of applications, but then again, it is not a black or white picture. The server will remain important for web applications for a very long time to come.
Yes, you do. Now take out your textbook and turn to Chapter One. ;)
Honestly, though, to answer your question, I don't think it's ever "unavoidable," no; you can always code for the absence of JavaScript. (Indeed, usability best practices dictate you at least try to "gracefully degrade" the user experience for browsers that don't support it, or for users who choose not to.) In the beginning, of course, there was no JavaScript -- but there was still the Web. It just, well, kinda sucked.
There's no simple answer, but if you absolutely must have one, the most straight-ahead one I can think of is to use JavaScript to improve the user experience. Secondarily, use it to shift the workload from your server toward the browser (Hello, Ajax!) -- validation, state, etc. Those are two big reasons, broadly stated, IMO.
At a stretch, you could do everything via server-side programming. Some things will be painfully slow and difficult to pull off right, but it is possible. If you want to see something clever done with nothing more than CSS, try out the search feature on lxr.mozilla.org with scripting disabled.
Practically though, the best places to use javascript are where it'd otherwise disrupt the flow of what the user's doing - the AJAXy things on here are all pretty good examples, as is the realtime preview (everyone should have one of these!)
If it provides significant benefit, then it's completely fine to use it. But please, don't make it required unless the server-only equivalent is needlessly complicated.
I never want to choose JavaScript, but it becomes unavoidable when clients want a decent web app. JavaScript has the unique feature of low latency feedback in a browser - server side code doesn't.
Also, there are a (rather limited) number of times when it's actually easier to bust out some JQuery for formatting rather than dealing with ASP.NET's event model to manipulate client elements. But, I'd say those are relatively few.
If you are looking for a responsive UI and want to avoid JavaScript, consider some of the RIA technologies such as Flex, Silverlight or JavaFX. I've been developing with Flex since v1.5 and find it very capable and productive. Silverlight is getting significantly better with each release, too.
GWT is a nice system that compiles java code into javascript which becomes kind of like a "Machine language" for the browser--you never have to consider it.
I believe most google apps are written using GWT. It's pretty slick.
All your source code is pretty much straight Java using a library somewhat like Swing.
JavaScript is not a necessity but, coupled with the DOM API, it provides a very useful medium for gradually improving the user experience of your site. Obviously the extent to which this is true is dependent on how well you execute these enhancements, don't just use JavaScript for the sake of it; it's a design decision, and should not be taken lightly.
Sharing the load between client and server.
Try to keep it natural. Use it to enhance little things, do not built your whole application on JS.
A good way to measure the breadth of your skills is when "Do I have to use ..." starts disappearing from your conversation. Hopefully you get to the point where a language is just a language, and you develop a feel for what the right tool is for the job, and can use it as comfortably as any other language.
If it's any consolation, there's increasing evidence that there's enough conventional wisdom and available toolsets that developers are increasingly preferring javascript. I personally like it for its conciseness and easy exensibility - once you get to know it.
You don't have to.
But if you want to provide UI extras like autocomplete, drag and drop, richer form entry fields, etc.…, Javascript is your only answer.
Of course you can abstract that Javascript generation out to the server side but you'd still be tussling with Javascript, albeit via programmatic code generation.
When you create a Rich Internet Application which gets loaded into a browser and which communicate to a Web Server with an Open API (like SOAP, JSON etc)
"Javascript over server side " JavaScript is client side, not server side.
You would still need to run server side stuff to get the data from the server. Javascript just gives you more control on how the client receives the data from the server.
JavaScript is unavoidable when you want a certain dynamic feature on your website which is not supported by default.
Dynamic feature
- without JavaScript: you can use CSS to change background of an element when the mouse is over the element. You can do the same thing with using JavaScript.
- Only in JavaScript: When you click the element with your mouse, the element disappears. Don't think it is possible in CSS(maybe you be able to use :active in CSS on some elements. Never tested it myself).