Monthly Archives: September 2007
- We’re working on a new internal search tool that will make it easier for our staff to find the Support information they need to assist you.
- We’re upgrading our department’s internal web sites to Microsoft SharePoint 2007. If it were a straight upgrade, it wouldn’t require much effort, but we’re also revamping the web sites to reflect the recent changes to our organization (you can read about those changes in this recent post’s interview with Aaron Zureick, Operations Manager for ESRI Support Services).
- We’re wrapping up a pilot project to evaluate the benefits of a screen-sharing technology that our support analysts can use when helping customers.
P.S. My next post will probably be on the new blog platform, as mentioned in my last post. I’ll throw a quick post up to confirm this when the move actually takes place.
The only other news of note at the moment is in regards to this blog itself: the Support Center News blog will soon be migrating to a newer, more robust blogging platform. All of ESRI’s existing blogs will soon be on the new platform, which should provide some nice benefits for both our readers and those of us who manage blogs here at ESRI.
If you’re subscribed to this blog via Feedburner you shouldn’t have to change a thing, as I’ll just update the feed URL there once the blog has been moved. We’ll also update all the hard links to this blog from the Support Center pages. However, if you use a shortcut or favorite in your browser to get to this blog, you’ll have to update that yourself.
This blog site will remain active for a while, to help let everyone know about the move to the new platform. I’ll let everyone know when the move actually takes place, but it should be in the next week or two.
Bugs Online: FAQsQ: What is Bugs Online?
A: Bugs Online is a public, searchable database containing known ESRI software issues.
Q: How do I access Bugs Online?
A: To access Bugs Online, follow these steps:
- Go to the ESRI Support Center web site (http://support.esri.com).
- Log in using your ESRI Global Account. If you think you have an account but aren’t sure of your username or password, click here. If you don’t have an ESRI Global Account yet, click here to create one.
- Enter keywords or a bug ID number into the Search box near the top of the page, then click Go.
- The search results will include items from Bugs Online, if any were found.
Q: Is there a way to browse the Bugs Online database directly?
A: At this time, the only way to access Bugs Online is by performing a search on the Support Center web site as described above.
Q: Can I search Bugs Online from other ESRI web sites?
A: At this time, the only way to access Bugs Online is by performing a search on the Support Center web site as described above.
Q: How can I find a bug in Bugs Online when I don’t have the bug number?
A. In addition to searching by bug number, you also have the option to search for the bug by a keyword or phrase.
Q: When I search for a bug by keywords or phrases, the search results includes bugs that don’t have those keywords or phrases in their Synopsis. Why does this happen?
A: This happens because the search looks not only at the Synopsis, but also at the rest of the notes in the bug.
Q: Why isn’t ESRI publishing the full notes for each bug?
A: There are several reasons, but a big one is customer confidentiality: Many bug reports include specific information about our customers and their projects, and ESRI is committed to keeping that information confidential.
Q: Why can’t I find a particular item in Bugs Online?
A: There are two main reasons why a particular item may not appear in Bugs Online:
- The item may have been marked as an enhancement. For the time being, we have decided to exclude enhancements from Bugs Online. We’ve done this because enhancements represent potential improvements to future versions of ESRI software, whereas bugs represent known issues in the existing, released versions of our software.
- The item may still be under review. When a new bug is submitted, it gets reviewed to confirm the details of the issue. We also review to make sure the issue is described in a way that should make sense to users (and not just our development teams).
A: You may have encountered a new bug! Call ESRI Support Services at 1.877.377.4575 or submit a request via the Contact Support Form (available here) and provide the details of the issue you are encountering.
Q: Why is ESRI publishing Bugs Online?
A: We want to do everything we can to help you be successful with our software. By publishing Bugs Online, we’re making it possible for you to research potential issues before beginning a project. Also, if you encounter issues during a project, you can research to see whether the issue is already known to ESRI or not, and save considerable time when contacting ESRI Support by quickly identifying the issue.
Q: What are the different bug severities and what do they mean?
A: The bug severities are defined as:
- Low – Failure or error with minor functionality.
- Medium: – Failure or error with major functionality.
- High: – Crash, data corruption or loss of data.
- Critical: – Showstopper issue.
A: The bug statuses are defined as:
- New – The bug has been logged by ESRI Support Services and is in the process of being reviewed.
- Open – The bug has been assigned to a programming lead, who is responsible for its continued evaluation and resolution.
- Deferred – The bug will be considered for a future release.
- Contact Support – Please contact ESRI Support Services for additional details.
- As Designed – The software is behaving in a manner consistent with ESRI’s intent.
- Documented – The specific behavior referenced in the bug is documented by ESRI.
- Non-reproducible – The behavior specified in the bug could not be reproduced given the current information included in the bug report.
- Known Limit – The bug cannot be resolved due to a limit in the specified application or environment.
- Duplicate – The bug is a duplicate of another bug.
- Resolved – The bug has been addressed for the next software release.
A: Call ESRI Support Services at 1.877.377.4575 or submit a request via the Contact Support Form (available here) and provide the bug number (for example, NIM001234) in the request.
Again, these FAQs will soon be posted somewhere a bit more accessible on the Support Center. If you have other questions about Bugs Online, leave me a comment, and I’ll do my best to respond.
- Bugs Online: As with most projects of this magnitude, there’ve been a few unexpected hang-ups. In particular, the process of preparing the bug synopses for public consumption is taking considerably longer than we expected. I’ve been personally involved in that effort, and the drill goes like this: Read the bug synopsis, read the detailed bug notes, and make sure the synopsis is an accurate, complete and comprehensible representation of the essense of the bug. We’ve had teams of people putting in extra hours towards this effort, and we’re working our way through them… and let me tell you, it’s about as much fun as trying to get a GPS reading inside a sewer system. But you won’t have to wait until we finish: we’ll be releasing Bugs Online once a good majority of the bugs are ready to go, and we’ll finish prepping the remaining bugs after that. Thanks for your patience, and don’t worry, we should have Bugs Online up and running well before the end of summer.
- Support and Screen-Sharing: Starting next week, some of our Support analysts will be participating in a trial run of an updated version of the screen-sharing technology mentioned in my last post. If you’re lucky enough to get to experience the updated screen-sharing process, please make sure to fill out the Customer Survey that will appear at the end of the screen-sharing session. We’ll be using your feedback to help determine whether and how to proceed with the upgrade.
Interview withJason: Thanks for taking the time to chat with me today, Aaron. Maybe we could begin with you telling us a bit about your history here at ESRI.
ESRI Support Operations Manager
Aaron: I’ve been with ESRI a little over eight years now. I started out as an analyst supporting ArcInfo Workstation with AML, and then moved on to support Desktop when ArcGIS Desktop first came out. After that, I progressed into other areas, primarily ArcSDE and geodatabases. That was really where I spent my time as an analyst, more or less. I’ve also held several other roles in ESRI Support: I was a founding member of the Premium Support Group, a Team Lead for one of our support teams in the old Technical Support Department, the Assistant Manager of Technical Support, the Manager of Technical Support and now, after the reorganization, I’m the Operations Manager for ESRI Support Services.
Jason: That’s a lot of ground you’ve covered. Since you’ve brought it up, let’s talk about the reorganization of ESRI Support. Not too long ago, support was organized somewhat differently. Can you talk a little bit about how support’s been organized in the past, how it’s organized now, and why the change was made?
Aaron: Way back when, we had one support group, known as Technical Support. As our product line grew and as our user base grew, at some point it became necessary to have support that was specific to our customers who were developing their own GIS solutions using our products. To answer that need, ESRI created another support group, known as Developer Support. For a number of years we had Technical Support and we had Developer Support, and they both had clearly defined responsibilities and it was clear which group would handle which support calls. However, as our user base grew and as our product line matured, the line between what those individual groups did and what their purpose was became more and more blurred. So we ended up with two support groups that were big, that were basically doing the same support but moving in different directions in the way they did that support. That caused a lot of problems and was one of the main reasons we decided to look into reorganizing both groups into a more comprehensive and focused entity.
Jason: Okay. So Technical Support was doing things one way, Developer Support was doing them a different way – and the users were experiencing this difference?
Aaron: Yes, absolutely. Users could get different experiences every time they called Support depending on the product or question that they had. There were different call back times depending on which products they were calling on, there was a different experience for how the analysts interacted with the customers. There was a different depth or level of support that was given. The processes for escalating calls or pushing calls through some sort of QFE or Hotfix process differed. The ways we collected and processed feedback to development and sales and other departments was different and inconsistent. The list goes on and on.
Jason: So we fixed all that, right? (laughs) Seriously, though, it sounds like these may have been some of the main problems driving the effort to reorganize ESRI Support?
Aaron: With the reorganization, we wanted to put ourselves in a better position to interact with all our customers in a consistently effective way. It was confusing for customers when we had two different support groups with two different types of support contracts. It was also confusing internally here at ESRI – our own [non-support] staff weren’t sure which Support group to contact for help with internal or client projects. As an example, the folks in ESRI’s Sales and Marketing departments had to go to one support group for maintenance issues, and the other support group to discuss add-on support for certain developer products. It was confusing and a barrier to a lot of folks. Also, the organization within each of the old groups was fairly flat and wasn’t scaling well as the groups grew.
Jason: It sounds like all sorts of problems may have been solved by the reorganization of ESRI Support. So now, support is a single group called ESRI Support Services… but in a strange case of déjà vu, it has two groups: there’s the Operations Department, which you’re the manager of, and then there’s also a Business Department. This is somewhat surprising, given the problems that arose from having two support groups in the past – can you talk about the new structure and why it was chosen?
Aaron: The new structure ties in with scalability and effectiveness. Yes, we still have two groups in support, but they are focused on very different aspects of Support, as their names suggest. In the past, both of the old groups had a primary responsibility of helping and being responsive to customers. But we found that when call volume increased, other responsibilities started to fall by the wayside. These were secondary responsibilities that in some way helped the customer in a more indirect fashion, usually by helping ESRI Support function in more productive or efficient way. Those secondary responsibilities always gave way to the primary responsibility of directly helping customers with their technical issues. For example, organizing and evaluating and planning for the Support Center web site used to be someone else’s secondary responsibility, and when the calls got backed up, something was going to go on the backburner and it wasn’t going to be our responsiveness to the customer.
Jason: Right. And now that particular secondary responsibility is someone’s primary responsibility, namely, mine.
Aaron: Exactly. We took those things that were secondary responsibilities and we made them the primary responsibilities of the people in our Business department, separating them organizationally from the Operations department, which contains the analysts and managers who are focusing on the incoming calls.
Jason: What else goes on in the Business department?
Aaron: Besides the Support Center, there’s our User Advocacy Group, which analyzes issues and trends in our software and feeds those back into the software development process. Beth G. is heading up the UAG, and she works with our Development Technical Leads [DTLs] – these are new positions created during Support’s reorganization. DTLs work for ESRI Support Services, but they sit with our development teams and help prioritize issues and manage communications between Support and Development. The Business department also includes staff dedicated to documentation, internal reports, International Support, Offsite Support, and metrics and standards.
Jason: Let’s talk about your department, Operations: how is it organized, and why?
Aaron: We chose to organize Operations in much the same way as our Development teams are organized, to help our relations and communications with Development. We basically have four Units based on technologies: Desktop, Geodata, SDK, and Server. Each of these Units is organized the same way; they each have the same types of positions, and they’re built to be scaleable as we continue to hire more staff. The new structure also creates more advancement opportunities for the people who work here. In the past, if you were an analyst and wanted to be a technical person and develop a technical career, your choices were to remain an analyst, or leave Support. If you wanted to be a manager or supervisor, your choices were to wait around for a Group Lead and/or Manager position to become available, or leave Support. With our new structure there are many more options for movement and advancement while remaining a part of ESRI Support Services.
Jason: That’s a nice aspect, as I can personally attest to. You said that each Unit has a similar structure – what does that structure look like?
Aaron: There’s a Unit Manager who’s responsible for the overall health of their Unit, including operational efficiencies, how well we’re doing supporting the customers, the quality of the support that we’re giving, the health and attitude of the analysts and other staff in the Unit, and career development and long-term career development of the employees. Each Unit Manager also has two technical leads, there’s a Senior Support Technical Lead and a Development Technical Lead. The Senior Support Technical Lead [SSTL] is the internal support expert for their Unit. They help develop overall curricula for their Unit, they help new analysts build expertise, and they’re a point of contact for technical communications between the different Units. As I mentioned before, the Development Technical Lead [DTL] is a senior analyst who actually sits with the development team and participates in the development team’s processes. The DTL focuses on identifying and lifting up software quality issues that we see here in Support. The DTLs from each Unit work together in the User Advocacy Group to prioritize bugs and enhancements, they do trend analysis on issues that customers are reporting, and they’re a point of contact for technical communications with Development. The rest of the Unit is organized into Groups; each Group has a Group Lead who acts as both a direct supervisor and a technical resource for the analysts in their Group. Each Group has between four to eight analysts, ideally. Some of our Units have as many as four Groups already, and they’re meant to scale, so that regardless of how big a Unit gets, any supervisor should only have to manage somewhere between four and eight people.
Jason: I see. That’s a pretty deep organizational structure – certainly much deeper than it was before.
Aaron: Yes – it’s scaleable, and it really opens up a lot more advancement possibilities for our staff.
Jason: Great explanation. That should help paint a picture for our readers of how support is now organized, and the reasons for the change. So how’s the new organization been working out so far – has it been fairly successful?
Aaron: Yes, absolutely. Like with any major change in an organization, there’ve been some bumps as people have grown into their new positions, but we’re definitely seeing, internally, a lot of improvement in efficiency and in the supporting processes. It’s been a good eight months since we’ve reorganized and we’re starting to see some of the intended benefits. Our relationship with other internal departments is getting much stronger, our ability to do things quickly for the user and for the analysts are improving. We’re getting better at cataloguing the information that we get back from the users and turning it into knowledge base articles so it can help other users. One of our primary goals here in the Operations Department is to be able to get back to the customer the same day they log a call with us — in some areas we’re able to do that and in some areas we’re not there yet, but we’re making changes and looking forward to put ourselves in a better position to be able to do that.
Jason: Okay. I was going to ask what objectives you had for support operations for the future. That sounds like a good one. I’m sure all of our users would give that a thumbs-up. What other aspects of performance does Support measure and strive for?
Aaron: Sure. There’s quite a few metrics we look at for operational excellence. Obviously, one of them is the time it takes to get to a user after they log a call. Our primary goal is to have an analyst ready to speak with the user right when the user calls in, and we aim to provide that kind of service for a certain percentage of the incoming calls. That analyst may or may not be able to actually solve the user’s problem, but at least the user is talking with someone who’s in a position to help them out. In cases where this does not happen, getting back to the customer the same business day is our goal. Another metric we look at is the percentage of those calls that are directed to an analyst that are actually resolved on first contact – we look at both “time to ownership” and “time to resolution”. We can’t always control whether a resolution is possible or whether it’s well-received, but we can certainly look at resolution times as an overall statistic for calls and see how quickly we’re getting accurate information back to the user. We also look at surveys. Regardless of whether there was a solution or not, we want customers to have had a good experience with support. Did we do everything we could? Did we do the right thing for the customer? So we review the customer surveys and investigate into any low marks we receive. In addition, we perform incident quality evaluations on calls that come through Support. And we feed our findings, the good and the bad, back to the analysts so they know where they’re excelling and where they need to improve. There’s a lot of internal ways we monitor how our customers are being handled.
Jason: To wrap up, is there anything that you’d like to say to the readers of the Support News blog about support?
Aaron: I’d like to assure them that our overarching goal is to help them be successful using our software. We’ve been mostly reactive in the past, and we’re working towards being more proactive. We’re constantly looking for ways to change and adapt so we can provide a better service. We know there are rough times and we’re bound to run into issues now and again, so if you experience problems with our service, please let us know, and we’ll continue to refocus our efforts as necessary.
Jason: Thanks very much for your time, Aaron.
Aaron: Thank you.
- Revising our internal search tools. With the most recent set of Support Center improvements safely out to pasture, we’re turning our attention inward for a few weeks, with an eye towards improving the tools and resources that our support staff (both here in Redlands and at our Regional Offices) use while they’re assisting you with a problem or question. One of goals during this time of introspection is to revise our internal search tools, to give our staff a more central location and a more standardized way to find internal-only information stored in a variety of sources and formats. It will soon be easier for the ESRI staffperson helping you to search for answers in draft Technical Articles, select internal email aliases, and other ESRI-internal information stores.
- Planning for greater use of screen-sharing technology. If you’ve contacted ESRI Support for help with an issue, the analyst may have suggested using a nifty web-based technology to view the problem directly on your computer. Historically, analysts have been instructed to use this technology only in situations where it’s very important to be able to see your screen. For example, when installing ArcIMS with certain web server / servlet engine combinations, there are text-based configuration files that need to be edited very carefully, and if one character is wrong — a backslash instead of a forward-slash, for instance — it can cause problems that are very difficult to troubleshoot.
Of course, being able to see what’s happening on your screen could be helpful in resolving all sorts of other issues as well! So, we’re exploring options for making this screen-sharing technology more available and easier to use for our staff.
We’re very close to unleashing info about our creepy-crawlies onto the Support Center. It might even happen before my next post. At this point, we’re waiting on a few last-minute changes that will help make sure that the bug info you’ll be seeing will make as much sense as possible. If you haven’t already done so, go ahead and set up an ESRI Global Account; you’ll need to be logged in in order to see Bugs Online in your search results. There’s plenty of other advantages to being logged in, too… click here for the details.
Next week, we’ll see if Bugs Online has emerged from its cocoon. I may also have another interview to present next week — this time, I’ll be talking with Aaron Z., the Operations Manager for ESRI Support Services.
people behind the new ESRI Mapping Center blog and web site. If you haven’t visited the site yet, or even if you have, it’s well worth a visit: new information is added frequently, by both the Mapping Center team and the larger User Community.
Jason: So let’s start at the beginning: Where did the idea for the Mapping Center web site come from?
Charlie: It was something Aileen Buckley and I thought of, mostly Aileen. Initially, she was looking at the Project Center and realized its purpose was to cover the entire scope of a GIS project and how to use all the tools in a GIS to get the project done. We saw a pretty straightforward parallel in mapping: you often need to use a variety of software, techniques and processes together to produce a map. We saw how the Project Center was laid out, centered around the life cycle of a GIS project, and it gave us some starting ideas. It’s definitely evolved since then, but that was the initial idea.
Jason: That’s interesting – so the idea for the Mapping Center came from the Project Center. Not very many people know what the Project Center is, and that’s something we’d like to change, maybe revitalize the Project Center, maybe see how the Mapping Center works out and apply some of those ideas back to the Project Center. But back to the Mapping Center, when was it that you and Aileen had this initial idea?
Charlie: That was almost two years ago, and it took us about a year to sort out what the concept would be. We talked with Clint B., our director and our main stakeholder, and he thought it was a good idea. We talked a good bit about, okay, what kinds of content do we have? How would we organize that content on the site? How would people interact with the content? What kinds of needs would the people who would use the site have? We wrote up a document a little over a year ago that detailed all of that and then the rest of it was, you know, working with people here at ESRI to make it happen.
Jason: And you and Aileen were at the center of that effort. You two have worked together for some time, right?
Charlie: A little over four years now.
Jason: Besides the Mapping Center, what have you worked on here at ESRI?
Charlie: Let’s see, I started here almost fourteen years ago. I was in an ArcView GIS team before it was ArcView GIS, and I was originally a “quality assurance analyst”, one of the first people to have that title. I tested a lot of Avenue code and I wrote a lot of sample scripts early on. I soon became a cartography product specialist for ArcView, starting way back at version 2.1 and up through 3.1, and eventually became part of the ArcMap team and was the product specialist there. Oh, and there was a fifteen month space where we worked on the ArcView IMS extension, and I was sort of the unofficial product specialist lead for that by the time we finished. And then about five years ago I started working on this side project, Base map and Cartographic Data Modeling.
Jason: Are these the same data models that we see on the Support Center website?
Charlie: Yeah. It was around that time when we hired Aileen. The whole “best practices” thing was in some ways what got me wanting to work at ESRI in the first place. I found it really difficult for geographers to get their heads around GIS, which is pretty ironic in some ways, but at the same time, you know, geography curriculum doesn’t teach information modeling or understanding how to use the database. The fact is that all these things are tools with their own abstract applications, and geographers just use them in a specific context.
Charlie: And so, something I wanted to do for a long time was to explain how to think about GIS, from a practitioner’s standpoint, to explain how you actually get from one state of information to another.
Jason: And you’ve finally got an outlet for that explanation, in the shape of the Mapping Center.
Charlie: That’s right. When I learned GIS, I learned that there’s a database, there’s analysis, and then there’s communication of the results… but we don’t talk a whole lot about that last part. We need to pay more attention to communications theory, or from a broader perspective, we need to be thinking about modeling information to support the data management story, the analysis story and the communication story. If you look at it holistically, the Mapping Center shows techniques for handling the communications story, which is important.
Jason: Is the Mapping Center meant to tell a comprehensive story? It sort of seems like a collection of snapshots, where each snapshot describes a specific place within a specific scenario.
Charlie: That’s probably the way it’s going to seem for quite some time. Trying to explain in kind of an abstract or theoretical fashion, how to think about GIS doesn’t actually help you think about actually doing it effectively. But by us actually using ArcGIS to figure out examples about how someone might do a particular task in GIS or a map-making task, we start to see how to think about that task. Aileen and I have thought about these tasks from a couple of angles. Aileen looks at it primarily from a cartographic theory and principles standpoint — Aileen’s has a Ph.D. in cartography, and she teaches as a professor at the University of Redlands, and she’d been in academia for a number of years before that.
Jason: Wow. That’s great experience she’s bringing to the table.
Charlie: Absolutely. For my part, I look at it from the standpoint of, well, how do you get this task done in the software? What route does the data have to take in order to become useful in whatever map somebody needs to make? And so between the two of us we can explain what the tasks are, how to do them, and why you’d want to do them that way. That’s what most of the Mapping Center content is, and we’ve come up with a pretty straightforward formula for presenting the content in a way that feels almost like a tutorial.
Jason: I see. So your visitors get it all: the how, the why, the best practices, it’s all in there.
Charlie: That’s our aim.
Jason: Neat. I see you’re looking at a web site page indicating the number of people who subscribe to the Mapping Center RSS feeds. How’s that going?
Charlie: It’s actually kind of surprising, I hadn’t gotten to see this until yesterday, but it looks like Mapping Center is already one of the more heavily-used ESRI blogs. We’re definitely getting a lot of traffic on it, anywhere from two hundred to four hundred hits a day. So that’s actually telling us that people are interested in what the site and the blog. I’ve talked to a number of people who said they like it. Aileen and I have enough content, we could publish random content out there for years, probably. But our intention really is to have the users drive the choice of topics, and that’s actually starting to happen now. We have an Ask a Cartographer section that’s getting between two and five requests every day now.
Jason: People are writing in with questions about how to make maps?
Charlie: Exactly. People can read the documentation and find out what a function does, but how do you know how to use it for particular application? How do you think about it in a given scenario? That’s the type of questions we’re seeing. Some of them are straightforward answers and some of them are pretty complex. I’m working on one right now where the user asks how to choose a cell size when interpolating points in a raster. It’s a complex topic because it depends on their purpose.
Charlie: We’ve never written a help topic about it, and it’s a common enough task, and so it’s just a matter of sorting out the issues, like: How do you evaluate your point data to make sure it can support the cell size you’re asking for? How do you determine the cell size that’s going to make sense for the product you’re going to make?
Jason: Sounds like coming up with a good answer could require knowing some theory, some of the science.
Charlie: That’s true for some of the questions, yes. When it’s appropriate, we should offer more information about the theory. At the same time, we don’t expect to be the ultimate authority. There are experts out there in the user community who live and breathe this stuff.
Jason: Very true.
Charlie: And we also kind of hope that these experts find the Mapping Center blog and leave comments based on their own experience. Those comments would be more than my two cents worth, you know, more like twenty dollars worth!
Jason: It sounds like one of the things that you’re really hoping for is for the user community to get involved. I’ve heard that there’s a way for users to submit an entire post for the blog?
Charlie: Yes, and that actually happened for the first time yesterday.
Jason: Really? What was the post?
Charlie: A user in southern Illinois has created a layout using the default ESRI palette. She’s set it up with CMYK colors, because that’s how her organization specifies color values for their maps. There are several different plotters used to make final maps, and they each produce slightly different colors. So she just runs the layout through each plotter and hangs them up as posters on her wall as a reference, so she can be sure of getting the right colors. I think it’s good post in that it reminds people of a good practice, and secondly, here’s a real-world example of somebody using the approach successfully. This post was less than 150 words, and she thoughtfully included the MXD to share with other users.
Jason: That’s really great. It sounds like the blog is really starting to take off and the community is getting involved. Have you had thoughts about the future of the Mapping Center?
Charlie: As we prepared for this initial release, there were a lot of ideas that we lumped into a “Whatever’s Next” phase, and now we’re starting to sort those out in terms of, “What’s Realistically Next” and “What’s Still On The Horizon”. The thing we most want to see show up in the Mapping Center is a search for the general site. There’s a search in the blog, but we feel a little handicapped at the moment. Beyond that, we’re thinking of turning the Ask a Cartographer section into a forum—we’ve had dozens of good questions that, for now, only the person asking has seen the answer. We have another section in the works that we’re calling the Cartographer’s Eye, where we would take a map that we’re working to improve, show “before” and “after” pictures, and then talk about the processes used to make the improvements. These are often the same processes that we use to produce our User Conference presentations, or when we’re helping one of our colleagues make a better demo or map.
Jason: “Before” and “after” pictures — sort of sounds like you’re putting a map on a diet.
Charlie: (laughs) In a lot of cases that’s actually a good way to think about it. There’s lot people who think that the more information and detail you can stuff into your map, the better. I think it was Frank Lloyd Wright who said something to the effect of, “the design is done when you can’t take anything else out of it”.
Jason: Indeed. (laughs). I’m sure he’d be proud of your effort to apply his idea to the world of cartography. Before we wrap this up, is there anything you’d like to say to or ask of the people who read the Support Center news blog?
Charlie: I’d love to see more people commenting on the blog entries. I mean, this kind of blogging is sort of a new phenomenon at ESRI in some ways, and our users are still kind of warming up to it. And I’d like to point out that the blogs that have come up lately, like the ArcGIS Explorer blog, the Mapping Center blog, and the ArcGIS Server Development blog – these blogs have real people behind them who are working on them every day, who get the feedback and respond so that in a very real sense there’s someone at ESRI who’s listening if you’ve got something you want to add to the discussion.
Jason: That’s right. So you’d like to see more people taking advantage of that fact.
Charlie: Right. These blogs are moderated, but it’s pretty loose. Blogs are for the user community, for people who are trying to get work done I’m kind of curious to see how an online community of this nature forms and participates. I think we’re starting to see the beginnings of this and I’d like to see it grow so the community is contributing maybe twenty five and fifty percent of the content, so it’s not all just Aileen and I talking. We want our users to ground this blog in reality by taking part in it. If you want to see something discussed, you don’t have to write a post yourself — you can just ask us, “can we get a blog entry on this topic?” We’re usually able to respond to that kind of thing in a couple of weeks. On the other hand, if you do want to post something, we’ve got a way to do that, too – we figured out a way to accept submissions from the user community, both inside and outside ESRI. Just go to the Mapping Center web site and find the Submit a Blog Entry link on the far right.
Jason: Excellent. ESRI is really starting to turn towards increased User Community participation, and the Mapping Center is a good, early example of that turning. Thanks very much for taking the time to talk with me today, this has been enlightening.
Charlie: It’s been a pleasure.
Thanks again to Charlie, and congratulations to the entire Mapping Center Team on the success of the site and blog.
Mapping Center site. Well, the interview took place, but we’re still in the process of translating our garbled ramblings into something infinitely more readable. In the meantime, here’s news on a small recent change, an update on Bugs Online, and two more of my colleagues from ESRI Support Services (ESS) step onto the gleaming locomotive wonder that is the Support Center News blog.
The Small Recent Change:Some of you may have already noticed this (@Nir did… thanks Nir!): on the Search results page, we’ve changed the date range dropdown box. Instead of two boxes, there’s now only one, and more importantly, the default setting is now “unrestricted by date”. This means that by default your search results will include items from all of time (actually, just back into the mid 1990′s). If you know that the info you’re looking for is relatively new (or relatively old), use this dropdown box to restrict your search by date, and you should get a more relevant result set.
Search Results are “Unrestricted by Date” by Default
The Bugs Online UpdateThe mechanics of the new Bugs Online functionality is undergoing ESRI-internal testing, and the results are looking good. We’ve nearly completed making revisions to the Synopsis (subject line) of each bug, to turn them from ESRI-internal gibberish into something you’ll have a decent chance of understanding. When it goes live just a few weeks from now, Bugs Online will auto-magically appear in your Support Center Search results, but only if you’re logged in using your ESRI Global Account. To further whet your whistle, here’s a DRAFT screenshot of what you’re likely to see (minus the “ESRI Internal Only” note) when you click on a Bugs Online result:
Click for full-size image.
Introducing ESRI Support Services Staff: Beth G. and Mike H.It’s my pleasure to introduce two more of my colleagues: Beth and Mike. Beth’s name has come up in previous posts, and she’s going to share a little about the User Advocacy Group and how it functions. Mike and I used to work together on ESRI’s ArcIMS Support Team in years past, and he’s going to tell you what he’s doing these days, plus offer a few tips on using our Web-based Help systems.
This week I would like to start off by talking about ESRI’s Web-based Help systems, or “Web Help”. For those that were using ArcGIS Desktop products at 9.1, you may already be familiar with our webhelp, but for those using ArcGIS Server or ArcIMS this was something new that was added at 9.2. All our Web-based Help content is located at http://webhelp.esri.com; this site is your ticket to a wealth of information that can help you get started learning a product. “But I’ve got the Help that came in the product box… Why use the Web Help?” you might ask. Well for one thing, the Help that comes in the product box is the same now as it was when the product first shipped — it doesn’t get updated until the next product release. On the other hand, the Development teams at ESRI are committed to updating the Web Help on a very regular basis, and are always adding new topics and updating existing content as the need arises.
In the Web Help for each product you will find information about: Architecture of the product, licensing information, tutorials, how-to scenarios, definitions of terms and acronyms, troubleshooting steps for common error messages, and topics related to administration of server products. Another thing you may not know is that the Web Help is fully searchable from the ESRI Support web site. When you use the Support Center Search, you should see Web Help entries in the search results, marked like this:
Thanks Beth and Mike. Next time, I’ll hopefully have that interview with the Mapping Center folks ready to go, plus I’ll be mentioning another small change that’s coming soon, and describing how that small change will set the stage for some significant improvements later on.
- Promote the Customer Care site on the Support Center home page. Currently, the Support Center only has links to the Customer Service site.
- On the Support Center home page, move the Announcements section below the “Latest Additions” section.
- When offering video tutorials, podcasts or other downloadable or streamable media, list the running time. This will help users wondering whether to watch/listen now, or later.
- With the Support Center Search, add the ability to filter content by version, like the EDN web site’s Search does.
- On the AnswerTree (beta), display the “Start Over” button on each page, not just on the end pages.
Introducing a Few Familiar FacesStarting this week, you’re going to be seeing some new faces in the Support Center News blog posts. I’ve invited some of my colleagues to send in snippets of info about themselves and what they do here in ESRI Support Services. These snippets will appear from time to time, whenever my colleagues have some timely Support-related information they want to share. Of course, that information will also (when appropriate) go out to the Support Center in various forms of documentation. Readers of this blog have the advantage of finding out things sooner (perhaps even before they happen), and also of getting to know the people behind the information.
So without further ado… This week two of our senior Support staff, Hamid and Mark, would like to introduce themselves. Take it away, guys!
I would like to take this opportunity to let all of you know that we at ESRI are fully committed to listening to your feedback and using that information to make a change in our software. That’s right, your feedback is one of the most important sources of information for us to focus on important software enhancements and fixes. ESRI Support Services has dedicated staff who convene with the developers on regular basis to share user feedback, and this process is managed by my team, the UAG (User Advocacy Group). The take home message is: Your feedback is very important, we sincerely thank you for your candid feedback, and we would like to hear more of it to effectively make a change.
It’s exciting to see some of the things folks are doing with ArcGIS Server as they incorporate it into their custom applications. Please be sure to check out the documentation and samples available from our EDN website, http://edn.esri.com. The red “Code Exchange” tab will take you to the samples. Java developers, you now have your own gateway called EDN Java Central: http://edn.esri.com/index.cfm?fa=java.gateway
Finally, here’s an article about some of the online documentation improvements for Server that have been made recently:
I recommend periodically checking the ESRI support site as well as EDN, since the documentation is constantly evolving and improving.
Thanks, guys. That’s the news for this week; next week we’ll take a look at the status of Bugs Online (see last week’s post for details), and perhaps an interview with the people bringing you the Mapping Center web site. Stay tuned.
Actually, I’m managing to stay rather busy. There are blog posts to write (obviously), and several other projects clamoring for my attention. One of these involves coordinating with colleagues back in Redlands to put a few final tweaks on the new Search Results page enhancements.
I didn’t arrive in San Diego until Tuesday, so I missed the plenary session where Nick Frunzi presented (among other things) the following slide which lists a few of the ways ESRI is working to improve Support Services:
That last item is the announcement I hinted at in my last post: ESRI is working to give you access to information which has historically been internal-only. What kind of information? Well, how about bug reports? Yes, someday in the not-too-distant future you’ll be able to search the Support Center and learn about potential problems before beginning a project. Of course, you’ll also be able to search for bugs after you encounter them, to see if the bug has been reported to ESRI, and if so, what’s being done with it.
Tentatively named “Bugs Online”, this new Support Center feature is planned to go live in late Summer 2007, and will be integrated into the existing Support Center search. Here’s a few more details (as usual, all is subject to change):
It looks like the first release will be a public “beta” during which you’ll be able to access Bugs Online, albeit with somewhat reduced functionality and content. During the the beta, you should still be able to access most of the metadata for most of the bugs, including:
- Synopsis: A concise description of the problem and the circumstances under which it occurs.
- Submitted: The date the bug report was filed.
- Severity: Indicates how heavily the problem impacts those who encounter it.
- Version Found: The ESRI software version where the problem was first seen.
- Status: A short text description of where the bug currently is in our handling processes.
As mentioned in previous posts, our Support Center web developers have been busy working on improvements to the Search Results page. In fact, I was in a meeting recently where we went over the most recent updates, and things are looking pretty solid. Here’s what you can look forward to seeing very soon:
Click for full-size image.
Here’s what you’re looking at:
- A. Improved Filtering. We’ve organized the filters into three static columns for easier reading. There’s even a method to which filters appear in which columns. We haven’t labeled the columns because it’s supposed to be more of an intuitive thing, but I’m curious: can you tell what method we used to decide which filters should appear in each column?
There’s a bit of odd behavior with the filters that I’d better explain up front. If you click on a filter other than “All Results” (say, “Discussion Forums”), all the filters will remain visible in the box, but the number of hits will disappear from every filter except the one you clicked:
This happens because when a filter is applied, the only results that come back are the ones that make it through the filter. On the other hand, when “All Results” is selected, we get back all the results, and we can then count and display the number of results next to each filter. We’re working on a viable solution, but for now, the only way to see all the numbers is to select the “All Results” filter.
- B. Date Range and Sorting Options. You’ll soon have the ability to apply date restrictions and change sorting behavior right from the search results page. As the screenshot shows, we’re planning to set the defaults to return all content newer than 6 months old, sorted by relevance. You can quickly adjust the date range options and click Go (either Go button will work) to search other date ranges. If you click on the Date hyperlink, surprise surprise, the results will then be sorted by date, as you can see…
- C. Cleaner Results List. … in section C. We’ve moved the date over to the right, added a content type description, and cleaned up some other metadata that didn’t mean much to most people.