Latest Contributions by Noah-Sager

Esri Technical Support is unlike any other Technical Support on the planet. But if you’ve ever opened a Support case before, you already know that. We provide world class support to our customers to help make them as successful as possible with our technology. But if you’ve ever come to one of our conferences or technical workshops, you already know that. However, what you don’t know may mildly surprise you. I would like to take this opportunity to shed some light on how Support works, and help make you both more successful and more effective with your troubleshooting. Excited Esri Support I wrote a totally rad blog post back in the day about what it feels like to work as a Support Analyst. It’s a pretty sweet job, and after two years, I still maintain the sentiment that Support is full of super awesome and intelligent people who kick serious butt and take great pleasure in helping our customers. Therefore, it might (or might not) come as a surprise that in Support we can’t (all) be GIS prodigies with experience on every product or subject matter. Sometimes we need to do a screen-sharing session so we can both look at the same product/documentation together. Sometimes we have to test offline and get back to you later. Sometimes we need a senior colleague to assist, or need to transfer the case to another analyst who is better suited for the specific technology/question. I know that this is a racy topic, but my goal here is to concurrently increase our transparency and your success. To paraphrase our ultimate goal: we want to help you. I would put the emphasis on “want” in that statement to make sure that our intentions are clear: we want to help you. We also love you. Actually, love is a strong word, so let’s just say that we really really like you. So, you know that we like you, you know that we want to help you, now the next step is to help us help you. But the question is, how? Support Analysts at Work First, we’re all human beings. We think and we feel and we try really hard. We’re also professionals, so we will do our best to help you, and at the same time, achieve our own personal/professional goals. That’s a pretty vague statement, right? So let’s look at an example. Someone calls in with a question about the JavaScript API. I answer the question to the best of my abilities, but not everything worked out the way we wanted it to, and the customer gives me a bad survey. This hurts my feelings, but I talk to my manager and my manager talks to the customer, and we all learn something. This is another good nugget of information: every single survey is read and considered. If you have kind words to say, say them - we love to hear them. If you are upset and feel that something went wrong and have strong words to say, say them - we need to hear them too. Remember, as technologically savvy as we are, we are still human beings and thus imperfect and also warm and cuddly and willing to learn. Second, when you call/email/chat to create a new Support case, we do our best to route you to the correct analyst. Our analysts specialize in particular areas of our technology, so not everybody knows everything. You may need to be rerouted to accomplish this goal, but just remember that we want to help you. We are proud to say that we are constantly working on refining and streamlining this process. Even though it’s not perfect, it’s always getting better. Kind of like a piece of software, case management is always being upgraded based on user feedback and experience. Also, when logging new cases, please include as much relevant information as possible, including specific product names and versions. Copy and paste is both of our friends. Test applications and screenshots are good buddies too. We also accept cookies. Support Celebrates GIS Day Third, you know how they say at the end of some commercials: “Prices and participation may vary”? Well, it’s the same with Technical Support. The prices of our services, such as a Support contract, Premium Support contract, or a Professional Services contract, do indeed vary. Our Customer Service representatives or Account Managers would be happy to review these options with you. With regards to participation, your participation is vital. We need to be able to have an honest conversation, and we need you to hold up your end just as we need to hold up ours.  If you leave to go on vacation, or can’t work on something, just let us know so that we can temporarily close the case and then reopen the case when you are ready to participate. Remember that we really, really like you, but without you, there is no case. Fourth, we maintain a standard of one topic or question per case. Why do we do this? For many well-intentioned reasons. For one thing, it’s good for our internal resources. We are able to track and research on past cases, and it’s quite helpful to have one question and one answer in each case in order to quickly find the information that we need to help future customers. Another reason is that we need to help all of our customers in a timely manner. If there is another question or issue that arises during the current case, we need you to create a new case that goes back in the queue so that the next available analyst can handle it. This way we always work on a “first come first served” basis, and we don’t (read: can’t) play favorites. Lastly, we do this because there must be a light at the end of the tunnel. These cases could drag on for longer than necessary if we don’t have a firm resolution timeline in mind. Support Analysts at a Hackathon Sixth (I skipped number five to save space), some of us use a lot of exclamation points in our emails and chat interactions. You may find this bizarre or annoying, but believe me, we are not being annoying! We are also not shouting or saying things emphatically. We just do it because it seems nice that way!! Seventh, we love closing Support cases. It’s a bit hard to explain, but when we’re given a problem, and we can figure it out and send someone on their way towards success, it feels so freaking good - you have no idea. And even when a case gets closed, we can still re-open it if something bubbles up down the road, or if you have a question about a topic that was covered during the case. Nothing is forever, not even closure. I write these words to help. Real life is about people trying to live their lives to the best of their abilities, so why should professional life be any different? We’re here to help, plain and simple. Maybe they do things differently on Mars, but here on Earth, this is what world class technical support looks like. And you’re a part of it. Support Analysts at a Another Hackathon Noah S. - SDK Support Analyst ... View more

At Esri Technical Support, we enjoy working with JavaScript to create powerful web applications. I’d like to take this opportunity to share different ways of listening for events in our JavaScript API with On Style Events, which is the recommended pattern for event handling. As a previous blog focused on different patterns of event handling, this blog will stick with the best practices, tips, and tricks. Note: Click images to enlarge. The modular On Style Events (which means something like à la mode in French) are a bit different than Connect Style Events. Why does this matter? Because On Style Events are the recommended way to listen for and handle events with the ArcGIS JavaScript API. See the screenshot below for snippets of event styles. Snippets of Event Styles Since version 3.5 of the JavaScript API, these event handling functions receive a single event object from which all the event object properties can be accessed. Typically, this object is called event or evt in our samples. Instead of juggling multiple objects like with Connect Style, we can now dig into one object to access the information we need. There are two ways to use the On Style Events - with and without Dojo. The syntax for these event styles can be found in the JavaScript API reference. Let’s look at a couple code snippets to compare On Style Events with and without Dojo:on = with Dojo (on is an alias for the dojo/on module) on(map, ’zoom-end’, function(evt) { console.log(evt.extent.xmin); console.log(evt.zoomFactor); console.log(evt.anchor.x); console.log(evt.level); }); map.on = without Dojo (map.on means we can do this event ourselves) map.on(’zoom-end’, function(evt) { console.log(evt.extent.xmin); console.log(evt.zoomFactor); console.log(evt.anchor.x); console.log(evt.level); }); By examining the above code snippets, we can see that the main difference when using On Style Events is in what the event listeners return. We can also see similarities among the new styles of event handlers, but there are important differences worth exploring. Not bad, right? For more better understanding, here's a real-world example. You can follow along at home with the JavaScript Events application hosted on jsfiddle.net. Use the following instructions to follow along (I used Google Chrome for this example): 1. Open the application in your browser. 2. Press F12. 3. Navigate to the Console Tab, if not open already. The following screen displays: JSFiddle This application shows the functionality of dynamic layers and our elegant dark gray basemap tiles (you can also try the application live here: JavaScript Events application on GitHub). As you zoom in and out of the map, different layers become visible as indicated in the lower-left information box. There are six event listeners in this application. Let’s go through them one by one and see what they do.1) map.on("load", function() When the map first loads, it immediately runs the unnamed function. This listener will only be called once while the application is running, and the listener does not take any arguments in the function. The purpose is to define the four other event listeners and to call the updateScale() function. This allows the scale to be defined in the information box without panning or zooming.2) map.on("zoom-end", updateScale) After zooming in or out of a map, this event listener will call the updateScale() function. This function updates the map scale in the information box and in the Console tab. This listener does not take any arguments in the function, either. See below for the event handler: function updateScale() { dojo.byId("map-scale").innerHTML = dojo.number.format(parseInt(map.getScale())); console.log("Map scale: " + dojo.number.format(parseInt(map.getScale()))); } 3) map.on("pan-end", updateExtent) When a user pans around the map, this event listener will call the updateExtent() function, which will update the map extent in the Console tab. This listener takes the generic evt argument in the function.Pro tip: There are many other attributes that you can dig out of the evt object. To see what is available, use the following steps (I used Google Chrome for this example): 1. Press F12 to open the developer's tools. 2. Navigate to the Source tab. 3. Find the section of code with this event handler (around line 170). 4. To set a breakpoint, click the line number to the left of the code. See below for a screenshot of this process. Breakpoint in Sources tab (Google Chrome) 5. Refresh the application, and when the application pauses on the breakpoint, switch to the Console tab and type “evt” into the prompt. You can now expand the evt object to see what’s there and experiment with how to call it. View the screenshot below to see how the evt appears in the Google Chrome Console tab. evt in Console tab with Google Chrome See below for the event handler: function updateExtent(evt) { console.log("Map extent"); console.log(" XMin: " + evt.extent.xmin); console.log(" YMin: " + evt.extent.ymin); console.log(" XMax: " + evt.extent.xmax); console.log(" YMax: " + evt.extent.ymax); } 4) map.on("zoom-start", updateOldLevel) When a user zooms in or out of the map, as soon as the zooming action starts, this event listener will call the updateOldLevel() function. This updates the zoom level of the map in the Console tab. Again, the listener takes the generic evt argument in the function. Please see below for the event handler: function updateOldLevel(evt) { console.log("Map zoom level was: " + evt.level); } 5) map.on("zoom-end", updateNewLevel) When a user zooms in or out of the map, as soon as the zooming action stops, this event listener will call the updateNewLevel() function. This updates the zoom level of the map in the Console tab. Notice that it again takes the generic evt argument in the function. Please see below for the event handler: function updateNewLevel(evt) { console.log("Map zoom level is: " + evt.level); } 6) usaLayer.on("load", load) When the application first loads the usaLayer map service, this event listener calls the load() function, which displays the minScale values for each layer in the Console tab. If you open the map service from REST (http://sampleserver6.arcgisonline.com/arcgis/rest/services/Census/MapServer) and compare the minScale values for each layer, you see that the dynamicLayerInfo class in the code overrides each layer, which is pretty interesting. Notice that it again takes the generic evt argument in the function. Please see below for the event handler: function load (evt) { console.log("layer 1 minScale: " + evt.layer.dynamicLayerInfos[0].minScale); console.log("layer 2 minScale: " + evt.layer.dynamicLayerInfos[1].minScale); console.log("layer 3 minScale: " + evt.layer.dynamicLayerInfos[2].minScale); console.log("layer 4 minScale: " + evt.layer.dynamicLayerInfos[3].minScale); } For most of you, this is a refresher about working with On Style Events and the JavaScript API. But also for most of you, this will be new and exciting information to take your web apps (and salaries) to the next level. Let’s take a minute to review what we learned here. On Style Events have been around for a while and are slightly different than Connect Style, but are just as easy to use. On Style Events are simple and powerful ways of listening and handling many different event patterns. You can dig into all the arguments in the Console tab by setting a breakpoint and calling the argument object "evt". Please consider reading our Concepts documentation for more information about working with events in the JavaScript API:https://developers.arcgis.com/javascript/jshelp/inside_events.html Stay tuned until next time, when we discuss how to make your map "pop" with the new dojo.redecorate method. Happy eventing! Noah S. - SDK Support Analyst ... View more