Wat zit er in een naam: Wanneer Bekend = Onbekend

JoshuaBixby

<\/HEAD>

Dit is het vierde deel in een serie van vier over de uitdagingen van het benoemen van nieuwe functies in softwareapplicaties; met name de gevolgen wanneer het benoemen tekortschiet.  Het eerste deel in de serie<\/A> bekijkt een geval waarin de naam van een nieuwe functie duidelijk en beknopt het gedrag van die functie beschrijft.  Het tweede deel in de serie<\/A> bekijkt datzelfde geval wanneer nieuwere functionaliteit het oorspronkelijke gedrag van die nieuwe functionaliteit verandert.  Het derde deel in de serie<\/A> bekijkt hoe de documentatie is veranderd om deze gewijzigde functionaliteit aan te pakken.  En tenslotte bespreekt het vierde deel in de serie<\/STRONG> wat dit allemaal betekent voor eindgebruikers en ontwikkelaars.<\/EM><\/EM><\/P><\/P>Wanneer iemand al lange tijd een softwareapplicatie gebruikt, zeg ArcGIS Desktop al 10 jaar of langer, is het niet helemaal ongebruikelijk dat een gebruiker vastgeroest raakt in zijn/haar gewoonten, misschien zelfs een beetje zelfgenoegzaam.  Dit gebeurt niet alleen bij het gebruik van software, maar ook bij het lezen van softwaredocumentatie.  Immers, als je de software al meer dan 10 jaar gebruikt, weet je natuurlijk wat de documentatie zegt en precies hoe functies werken, toch? <\/P><\/P>Het is rond deze tijd dat RTM, STW, of misschien GIYF opmerkingen kunnen beginnen te verschijnen als reactie op iemands vragen in forums, lijstservers, enz....  (Ik weet het, forums en lijstservers zijn zo Web 1.0, maar ze zijn nog steeds werkpaarden voor veel GIS-beoefenaars<\/EM>).  Maar wat als je de handleiding hebt gelezen, op het web hebt gezocht en Google of andere zoekmachines grondig hebt geprobeerd.  Soms is het echte antwoord WABM, en ik denk dat dat is wat we hier hebben als het gaat om in-memory workspaces en achtergrondverwerking in ArcGIS.<\/P><\/P>Als ik naar de eerste drie delen in deze serie kijk, moet ik denken aan de nieuwste documentaire van Errol Morris, of tenminste de titel ervan:  The Unknown Known.  Op veel manieren voel ik dat de in-memory workspace en de bijbehorende documentatie een unknown known vertegenwoordigen.  Geven we Esri het voordeel van de twijfel en gaan we ervan uit dat er ten minste één ontwikkelaar of groep ontwikkelaars is die echt begrijpt hoe in-memory workspaces zouden moeten werken, dan hebben we eigenlijk een situatie waarin de documentatie volledig heeft gefaald om die informatie over te brengen.  De informatie over in-memory workspaces is bekend binnen de besloten muren van Redlands maar onbekend voor mensen die daadwerkelijk met de software werken en ontwikkelen.  Vanuit het perspectief van de eindgebruiker is het een unknown known, of misschien voor sommigen zelfs een unknown unknown.<\/P><\/P>De unknown knowns stoppen niet alleen bij in-memory workspaces.  Voor iedereen die met Esri-software heeft gewerkt, vooral Esri Support, weet hij/zij dat slechts een fractie van de ingediende bugs openbaar wordt gepubliceerd in ArcGIS Resources.  Bijvoorbeeld, er zijn 4 open bugs gerelateerd aan in-memory workspace gekoppeld aan het klantnummer van mijn organisatie en toch is geen enkele daarvan vindbaar in ArcGIS Resources.  Het is één ding dat Esri Development hun eigen bugtrackingsysteem heeft en die informatie niet openbaar maakt, maar het niet publiceren van bekende bugs uit het bugtrackingsysteem van Esri Support creëert veel unknown knowns, d.w.z. Esri weet dat er een probleem is met de software maar deelt dat niet met gebruikers.<\/P><\/P>Dus wat betekent dit allemaal of wat is het belang?  Verspilde tijd, verminderde productiviteit, gebrek aan vertrouwen in de software en meer....  De kosten van slecht gedocumenteerde informatie worden gedragen door de eindgebruiker, en helaas ben ik daar ook onderdeel van.  Wanneer de keuze voor GIS-software persoonlijk is, heeft de eindgebruiker de keuze om andere GIS-software te verkennen en mogelijk te gebruiken; maar wanneer de keuze voor GIS-software door een organisatie voor iemand wordt gemaakt, moet de eindgebruiker gewoon omgaan met verloren tijd, productiviteit en frustratie door te werken met software die slecht gedocumenteerd is of niet correct werkt.  Unknown knowns ondermijnen het potentieel van software en kunnen nieuwe functionaliteit veranderen in weinig meer dan marketinghype.<\/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.