Was steckt in einem Namen: Wenn Bekannt = Unbekannt

JoshuaBixby

<\/HEAD>

Dies ist der vierte Teil einer vierteiligen Serie über die Herausforderungen bei der Benennung neuer Funktionen in Softwareanwendungen; insbesondere die Konsequenzen, wenn die Benennung unzureichend ist.  Der erste Teil der Serie<\/A> betrachtet einen Fall, in dem der Name einer neuen Funktion das Verhalten dieser Funktion klar und prägnant beschreibt.  Der zweite Teil der Serie<\/A> betrachtet denselben Fall, wenn neuere Funktionalität das ursprüngliche Verhalten dieser neuen Funktionalität verändert.  Der dritte Teil der Serie<\/A> zeigt, wie sich die Dokumentation geändert hat, um diese veränderte Funktionalität zu adressieren.  Und schließlich diskutiert der vierte Teil der Serie<\/STRONG>, was das alles für Endbenutzer und Entwickler bedeutet.<\/EM><\/EM><\/P><\/P>Wenn jemand eine Softwareanwendung schon lange benutzt, sagen wir ArcGIS Desktop seit 10 oder mehr Jahren, ist es nicht ungewöhnlich, dass ein Benutzer in seinen Gewohnheiten festgefahren ist, vielleicht sogar ein wenig selbstzufrieden.  Das passiert nicht nur bei der Nutzung von Software, sondern auch beim Lesen von Softwaredokumentationen.  Schließlich, wenn Sie die Software seit mehr als 10 Jahren verwenden, wissen Sie natürlich, was die Dokumentation sagt und genau, wie Funktionen funktionieren, oder? <\/P><\/P>Etwa zu dieser Zeit können RTM-, STW- oder vielleicht GIYF-Kommentare als Antwort auf Fragen in Foren, Mailinglisten usw. auftauchen...  (Ich weiß, Foren und Mailinglisten sind so Web 1.0, aber sie sind immer noch Arbeitspferde für viele GIS-Praktiker<\/EM>).  Aber was ist, wenn Sie das Handbuch gelesen, im Web gesucht und Google oder andere Suchmaschinen intensiv genutzt haben?  Nun, manchmal ist die wirkliche Antwort WABM, und ich denke, das haben wir hier im Zusammenhang mit in-memory Workspaces und Hintergrundverarbeitung in ArcGIS.<\/P><\/P>Beim Durchsehen der ersten drei Teile dieser Serie muss ich an den neuesten Errol Morris-Dokumentarfilm denken oder zumindest an dessen Titel: The Unknown Known.  In vielerlei Hinsicht habe ich das Gefühl, dass der in-memory Workspace und seine Dokumentation ein unbekanntes Bekanntes darstellen.  Unter der Annahme zugunsten von Esri, dass es mindestens einen Entwickler oder eine Entwicklergruppe gibt, die wirklich versteht, wie in-memory Workspaces funktionieren sollen, haben wir im Grunde eine Situation, in der die Dokumentation völlig versagt hat, diese Informationen zu vermitteln.  Die Informationen zum in-memory Workspace sind innerhalb der abgeschotteten Mauern von Redlands bekannt, aber für die Menschen unbekannt, die die Software tatsächlich nutzen und entwickeln.  Aus Sicht des Endbenutzers ist es ein unbekanntes Bekanntes oder vielleicht für einige ein unbekanntes Unbekanntes.<\/P><\/P>Die unbekannten Bekannten enden nicht nur bei in-memory Workspaces.  Für jeden, der mit Esri-Software gearbeitet hat, insbesondere mit Esri Support, weiß er oder sie, dass nur ein Bruchteil der gemeldeten Fehler öffentlich in ArcGIS Resources veröffentlicht wird.  Zum Beispiel gibt es 4 offene Fehler im Zusammenhang mit in-memory Workspace, die mit der Kundennummer meiner Organisation verknüpft sind, aber keiner von ihnen ist in ArcGIS Resources auffindbar.  Es ist eine Sache, dass Esri Development ihr eigenes Fehlerverfolgungssystem hat und diese Informationen nicht öffentlich veröffentlicht werden, aber das Nichtveröffentlichen bekannter Fehler aus dem Fehlerverfolgungssystem des Esri Supports schafft viele unbekannte Bekannte, d.h. Esri weiß um ein Problem mit der Software, teilt dies aber nicht mit den Benutzern.<\/P><\/P>Was bedeutet das alles oder warum ist es wichtig?  Verlorene Zeit, reduzierte Produktivität, mangelndes Vertrauen in die Software und mehr....  Die Kosten schlecht dokumentierter Informationen trägt der Endbenutzer und leider schließe ich mich da mit ein.  Wenn die Wahl der GIS-Software eine persönliche Entscheidung ist, hat der Endbenutzer die Möglichkeit zu erkunden und möglicherweise eine andere GIS-Software zu wählen; aber wenn die Wahl der GIS-Software von einer Organisation für jemanden getroffen wird, muss der Endbenutzer einfach den Zeitverlust, Produktivitätsverlust und Frust ertragen beim Arbeiten mit Software, die entweder schlecht dokumentiert ist oder nicht richtig funktioniert.  Unbekannte Bekannte untergraben das Potenzial von Software und können neue Funktionalitäten zu wenig mehr als Marketing-Hype machen.<\/P><\/BODY><\/HTML>

JoshuaBixby

A link to provide feedback does exist, as you point out.  You state you have used it, I have used it, and I am sure others have as well.  It would be interesting to know how much users do use it, or don't as the case may be.  As much as providing a link for feedback is a first step, there are other companies that went a step or two farther with their online documentation years ago.

Regardless of what one thinks of the content quality, the Microsoft Developer Network (MSDN) structure is quite a bit more robust than the structure of Esri's documentation.  For example, when looking up information on something SQL Server 2014 related, there is a link at the top of the page for "Other Versions."  When deploying and managing numerous versions of software within an organization, which I think is fairly common for larger organizations, it is quite handy to see the documentation from earlier versions via a simple link rather than searching on an entirely new subdomain like we have now between ArcGIS 10.3.x and earlier versions.

In terms of feedback, MSDN offers a "Community Additions" section at the bottom of pages.  The Community Additions section isn't just for people to provide feedback to MS about their documentation, but also for users to provide information to other users.  As much as I can start a new GeoNet post to share information I have learned about how an ArcPy method really behaves, I think having that feedback right in the documentation makes it much more accessible.