nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Please sign this petition to restore the previous ESRI website design!

MatthewGoulet1

Is it me, or have the recent changes to ESRI's resources web pages become way more difficult to use?

Personally, I strongly prefer the previous look/feel and have found this new layout and design to be very non-user friendly.

If enough people respond in agreement, perhaps we may implore ESRI to walk back these new designs.

Please reply if you agree.

Find more posts tagged with

Accepted answers

All comments

JeffPace1

I have to agree, the forced "mobilification" of the styling is terrible for desktop users, which i can only imagine are the bulk of the developers.

derekswingley1

As I said in the previous forum thread discussing the new design, we are not going to go back to the old design.

We've been listening and have been making changes to the site to improve usability. We moved away from a fixed grid for the main content areas (api ref, concepts, samples and tutorials) and have made the table of contents always visible.

One big thing the design did for us was to ditch the <frames> so that the URL in your browser accurately reflects the content that's currently displayed.

We are still missing search, but we are working on restoring that.

What specific things don't you like about the site? The site (content as well as design) is constantly evolving and if there's something specific you'd like changed or tweaked we can discuss that.

What does "forced 'mobilification'" mean? The site operates the same on mobile/tablets/desktop. In other words, it is not a responsive design.

JeffPace1

For me its the super stripped styling that looks like it was designed for a tablet. Tons of wasted white space, big fonts, etc..
Its just a personal preference I guess. As long as it is functional.

It just FEELS like (especially due to missing search) that styling is being forced over function. That is the wrong direction, imho.

to be short, it looks like it was designed by marketing, not a developer. Fine for the examples, not fine for an API

derekswingley1

Its just a personal preference I guess. As long as it is functional.

I agree, critiquing a design is subjective. Hopefully the site is still functional. With the exception of search (and I'm not trying to minimize the importance of search), the site should be more functional. It's much easier to link to specific resources.

A little more background on search... internally, we weren't happy with how search was working. The underlying search index was out of date and the infrastructure for maintaining the index was going to go away. We decided to re-launch the site without search since we didn't think anyone was actually using it because the results were so poor. Obviously we were wrong.

to be short, it looks like it was designed by marketing, not a developer. Fine for the examples, not fine for an API

We didn't quite go full Zeldman for the site but I'd be lying if I said we weren't at least a little influenced by design elements from the A List Apart crowd.

JeffPace1

Yes thats it. Its just a frustration with the way the web is going.

Desktop screens are getting more and more landscape. Content is getting more and more portrait. It just doesn't work together.

DianaBenedict

If I might make several suggestions:

1) it would help me if I could resized the left panel to either make it bigger or smaller so that I have more "usable" area in the content section

2) It would be extremely helpful if ESRI could provided an object model for the Javascript API. Having the text is great, but a picture/model can say a hundred words (or whatever the adage is ). Sometimes I feel like I am navigating all over the place to find the objects that I need .. a model would help tremendously.

3) Please update the samples to include the AMD style of coding. According to your own documentation

Dojo 1.7 (the version of Dojo used by version 3.0 of the ArcGIS API for JavaScript) fully supports creating classes and modules using Asynchronous Module Definition (AMD) style code while continuing to support the older, dojo.declare style of module and custom class creation

It seems like it will really benefit the developers going forward to have samples that show the new standards. I tried using the "SeatGeek" sample that you have and it did not work correctly - the sample is referencing an older version of the JavascriptAPI and when you plug in the 3.3 version it does not work. Also, your sample includes all the code in the HTML. I moved the code to a seperate js file and I am unable to get the ESRI modules to load correctly using AMD style programming. Your samples need to be updated to not only support the current version of your API but to help developers with moving forward.

To conclude, it seems like ESRI has already improved the Help site since it first came out and I have confidence that it will get better - Design. We appreciate your quick response. I do not feel like it is as cumbresome (since the fixes) but I do agree that there is a lot of wasted space (it's all personal preferences, right).

Just my two cents ... Thanks for listening!

derekswingley1

Yes thats it. Its just a frustration with the way the web is going.

Desktop screens are getting more and more landscape. Content is getting more and more portrait. It just doesn't work together.

My take is that the web is mimicking print more and more. As our displays become more capable (hi-def, retina, blah blah blah), content on the web can be presented the way content is presented in print. I personally like this trend. Take these two presentations of the same article:
http://bits.blogs.nytimes.com/2013/02/01/the-origins-of-big-data-an-etymological-detective-story/?hp
http://bits.blogs.nytimes.com/2013/02/01/the-origins-of-big-data-an-etymological-detective-story/?hp&pagewanted=print

Which do you like better? Even with the ads and additional junk, I prefer the first. The second, while it uses nearly all available space is harder to read because it is so wide.

CharlottePeters95540_1-1656562200312.png

JeffPace1

My take is that the web is mimicking print more and more. As our displays become more capable (hi-def, retina, blah blah blah), content on the web can be presented the way content is presented in print. I personally like this trend. Take these two presentations of the same article:
http://bits.blogs.nytimes.com/2013/02/01/the-origins-of-big-data-an-etymological-detective-story/?hp
http://bits.blogs.nytimes.com/2013/02/01/the-origins-of-big-data-an-etymological-detective-story/?hp&pagewanted=print

Which do you like better? Even with the ads and additional junk, I prefer the first. The second, while it uses nearly all available space is harder to read because it is so wide.

Fair enough, but the new site here is more like the second, just with a narrower width. It is the ads and "additional junk" that is the value add that feels like its missing.

Maybe not.

derekswingley1

If I might make several suggestions:

1) it would help me if I could resized the left panel to either make it bigger or smaller so that I have more "usable" area in the content section

Can you use the "Hide Table of Contents" link? If that doesn't work, the other option is to resize your browser window which will cause the content area to become bigger.

2) It would be extremely helpful if ESRI could provided an object model for the Javascript API. Having the text is great, but a picture/model can say a hundred words (or whatever the adage is ). Sometimes I feel like I am navigating all over the place to find the objects that I need .. a model would help tremendously.

We haven't had an Object Model Diagram (OMD) for the API since 2009. We'll look into publishing one again.

3) Please update the samples to include the AMD style of coding. <snip>

I'll get these updated, hopefully today. Edit: I'm only referring to the samples linked from the Dojo and AMD help topic.

To conclude, it seems like ESRI has already improved the Help site since it first came out and I have confidence that it will get better - Design. We appreciate your quick response. I do not feel like it is as cumbresome (since the fixes) but I do agree that there is a lot of wasted space (it's all personal preferences, right).

Thanks for the vote of confidence

.

Can we talk more about the wasted white space? Outside of the home page, I don't see it. I've attached a screen shot with some annotations, please provide feedback.

Screen shot 2013-02-01 at 10.19.06 AM.jpg

derekswingley1

the new site here is more like the second, just with a narrower width.

If you recall, the width of the content area was one of the initial sticking points when we launched the new design. We switched from a fixed layout to a fluid layout to address the "use the available space and don't make me scroll for days" feedback.

It is the ads and "additional junk" that is the value add that feels like its missing.

Maybe not.

That's the first time I think I've heard a consumer of web content refer to ads as something that add value

. But seriously, we are trying to keep it as simple as possible. If you follow a link to reference documentation for a class in our API, we're giving you that content. We're not wrapping it in social media icons, displaying our latest blog posts/tweets and telling you about all the other stuff happening in the Esri ecosystem. We give you a link to search for samples that use that class but that's it.

DianaBenedict

In my opionion, the white space that you indicated in the image above has been identified. However, I think the white space next to the class description (within the content page) is probably necessary. Otherwise, it will make the content feel too cluttered.

Thanks

JeffPace1

FAir enough. As a developer, i am used to (and prefer) api's to look like this

http://docs.oracle.com/javase/6/docs/api/

the value add is in the linking. Note every inch of the screen has value in some form.

derekswingley1

FAir enough. As a developer, i am used to (and prefer) api's to look like this

http://docs.oracle.com/javase/6/docs/api/

the value add is in the linking. Note every inch of the screen has value in some form.

I say this half-jokingly but am genuinely curious, is part of the problem the fact that our links are black instead of blue? Is there a search for those docs?

Using the oracle docs, how would you send someone a link to the doc for say... the AbstractCollection class reference?

derekswingley1

I tried using the "SeatGeek" sample that you have and it did not work correctly - the sample is referencing an older version of the JavascriptAPI and when you plug in the 3.3 version it does not work.

I updated the SeatGeek and EmptyLayer samples to use 3.3. Here's what I changed to get those working:

added link to esri.css
added locale: "en" to dojoConfig (see the 3.3 release notes, alternatively, could have removed lang="en" attribute from the HTML tag)
corrected "esri/Map" to "esri/map", this was necessary because the map module is map (lowercase "m") while the actual class is "Map" (uppercase "M"), require() needs the module name, not the class name.

KevinMacLeod1

Very good back and forth discussion on user interface here. Everyone making good points.

I agree with Jeff that maximizing screen real estate is important. Also, the use of columns and dividers to separate things on the old site made it easier on my eyes. Search is critical, particularly for someone just starting to learn the API and not exactly where to look to find something but "sort of" remembering, i.e. remembering a key word or phrase.

Although Derek you make a good point, the use of links for each page is great! Very helpful.

Jeff, regarding web layout trends, that's a great way to put it. Sites are becoming portrait (for mobile and tablet) while desktops continue to widen. It seems we as designers can address this through CSS and HTML 5, e.g. portrait and landscape device orientation detection, detecting the viewport size, etc. I'm working on that now for my Javascript API site.

We haven't had an Object Model Diagram (OMD) for the API since 2009. We'll look into publishing one again.

Aha, so that's what it's called! I saw what I think this is for Silverlight. It had the API spatially mapped out like a flow chart. That would be nice for new folks like myself. Just an idea. After all... we think spatially! 🙂

MarcoBoeringa

Derek,

A couple of quick remarks. One thing I think ESRI is slightly forgetting in the new design of the last couple of years, is that one of the most frequent ESRI website user groups are the developers and advanced (geodatabase) GIS managers, not just the ordinary ArcGIS or GIS webapplication users, the last group may not even know they are using ESRI software at all, nor have ever heard of the company or know what the ESRI acronym means!

Developers and data managers may visit the site on a daily basis to find important data and information to help them get along with their latest project. They aren't so much interested in "Communities", as each project they do may actually be in an entirely different "Community"... such is developer work... they simply want the quickest access to API, Help, whitepapers, technical papers there is to solve urgent issues they have and find out how to do things. And in terms of "Communities", the only thing they are probably really interested in, is the Forum pages, to get direct help of peers...

One example that could use improvement, is the link to the API (Help) references that is "hidden" under the "Help" menu option in the ArcGIS Resources section (http://resources.arcgis.com/en/home/), while I think many developers would prefer a separate direct API's menu option in the same main menu. This would also cut back on the great amount of links under the "Help" section.

The same link to the API's list could be under the important:
http://support.esri.com/en/
page, which already gives direct access to many important things for developers and GIS geodatabase administrators.

I think separating out the "Developer Help" from the other help sections ("ArcGIS Help", "Application Help" etc.), and giving a more prominent position to the API references with all the object models, interfaces etc, via a direct link in the main menu's of the Support and Resources pages would at least be one change of use to many. I also think "API (References)" is a better name for this than "Developer Help", as most developers are more used to that first term when searching for details on object models, classes, methods and interfaces.

StephenLead

We didn't quite go full Zeldman for the site but I'd be lying if I said we weren't at least a little influenced by design elements from the A List Apart crowd.

For what it's worth*, I'd argue that the two sites have very different purposes - ALA is optimised for reading articles, whereas the Esri site needs to be aimed at providing information.

But thanks for responding and making the recent changes, which are definitely making a difference.

* I realise it's not worth much 😉

derekswingley1

Developers and data managers may visit the site on a daily basis to find important data and information to help them get along with their latest project. They aren't so much interested in "Communities", as each project they do may actually be in an entirely different "Community"... such is developer work... they simply want the quickest access to API, Help, whitepapers, technical papers there is to solve urgent issues they have and find out how to do things. And in terms of "Communities", the only thing they are probably really interested in, is the Forum pages, to get direct help of peers...

One example that could use improvement, is the link to the API (Help) references that is "hidden" under the "Help" menu option in the ArcGIS Resources section (http://resources.arcgis.com/en/home/), while I think many developers would prefer a separate direct API's menu option in the same main menu. This would also cut back on the great amount of links under the "Help" section.

The same link to the API's list could be under the important:
http://support.esri.com/en/
page, which already gives direct access to many important things for developers and GIS geodatabase administrators.

I think separating out the "Developer Help" from the other help sections ("ArcGIS Help", "Application Help" etc.), and giving a more prominent position to the API references with all the object models, interfaces etc, via a direct link in the main menu's of the Support and Resources pages would at least be one change of use to many. I also think "API (References)" is a better name for this than "Developer Help", as most developers are more used to that first term when searching for details on object models, classes, methods and interfaces.

This is great feedback but it doesn't necessarily apply to the site we're discussing. I appreciate the feedback the support site and the current resource center but those are not sites that we (the JS API team) directly manage.

derekswingley1

For what it's worth*, I'd argue that the two sites have very different purposes - ALA is optimised for reading articles, whereas the Esri site needs to be aimed at providing information.

But thanks for responding and making the recent changes, which are definitely making a difference.

Thanks Steve. Just to clarify, I was saying our design decisions were influenced by those who write at ALA, not that we were directly inspired by http://alistapart.com/.

bbieb

Derek,
Do you happen to know when the Javascript team is going to fix the mobile samples? Everyone of the mobile samples error in IE 8.
Thanks.
brian

derekswingley1

Derek,
Do you happen to know when the Javascript team is going to fix the mobile samples? Everyone of the mobile samples error in IE 8.
Thanks.
brian

In the future, please start a new thread instead of piggybacking on an existing, unrelated thread.

That being said, we'll take a look at the mobile samples in IE8. Realistically, those are meant for browsers running on phones/tablets, not legacy browsers.

bbieb

In the future, please start a new thread instead of piggybacking on an existing, unrelated thread.

Sorry about that but I've contacted support multiple times and cannot get a straight answer. There is also a bug submitted, but of course, that is set to low priority. Since the API group is active in the forum, I thought I would take a chance (and at the risk of being scolded) to see if the issue could get elevated.

That being said, we'll take a look at the mobile samples in IE8. Realistically, those are meant for browsers running on phones/tablets, not legacy browsers.

Yes, you are correct but if you wanted to create a adaptive web page (to work on both platforms), instead of having 2 separate code bases, you would want the application to also work in IE 8. Our IE 7/8 usage is still 20% of all hits. Not something we can ignore.

derekswingley1

Sorry about that but I've contacted support multiple times and cannot get a straight answer. There is also a bug submitted, but of course, that is set to low priority.

Logging a bug is an acknowledgement that something is broken. I would also call that a straight answer. In this particular case, you're right, it's not a high priority to make sample that were designed for browsers on mobile devices run on legacy browsers.

Yes, you are correct but if you wanted to create a adaptive web page (to work on both platforms), instead of having 2 separate code bases, you would want the application to also work in IE 8. Our IE 7/8 usage is still 20% of all hits. Not something we can ignore.

In that case, don't use the mobile samples as the basis for your app. Or dig into the mobile samples yourself to address the shortcomings until we do.

In the future, you can always post your questions here but we'll ask for as much info as support: specifically outline what you're doing, what you expect to happen, what's actually happening and code to reproduce the problem you're having.

bbieb

Just trying to get something fixed with our application. And we felt that if we could get the samples working we could track down where our problem resides.

We've been working on the issue for several months. Including support calls. The original one was at the beginning of December.

One of our attempts to get it resolved is here.

I will delete my replies to clean up the this post.

Sorry for the inconvenience. It will not happen again.

Jaros_awKowalczyk

Maybe that will help 🙂
http://web.archive.org/web/20110615053733/http://resources.arcgis.com/

Join the Conversation

Signed in members can post, follow updates, and more. New here? Register a free account.

Quick Links

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.