Select to view content in your preferred language

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

3043
25
02-01-2013 04:53 AM
MatthewGoulet1
Deactivated User
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.
0 Kudos
25 Replies
derekswingley1
Deactivated User
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.
0 Kudos
DianaBenedict
Frequent Contributor
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
0 Kudos
JeffPace
MVP Alum
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.
0 Kudos
derekswingley1
Deactivated User
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?
0 Kudos
derekswingley1
Deactivated User
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.

0 Kudos
KevinMacLeod1
Frequent Contributor
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! 🙂
0 Kudos
MarcoBoeringa
MVP Alum
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.
0 Kudos
StephenLead
Honored Contributor
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 😉
0 Kudos
derekswingley1
Deactivated User

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.
0 Kudos
derekswingley1
Deactivated User
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/.
0 Kudos