Agreed, it's something that never happened. Might have been nice, but it's not the end of the world to need to create a replacement table.
Right now, almost four years after I first saw a beta "ArcGIS 11," I'm still switching from ArcGIS Pro back to the 32-bit app sometimes; this week when having stability problems while editing (merge, explode) and building geodatabase topology in ArcGIS Pro, I worked in ArcMap for a few hours, then was able to work with my changes in ArcGIS Pro, which I'd otherwise prefer to use.
After watching this feature request thread for a couple of years, I'm in a better place---because now I'll pick and choose among ArcMap, ArcGIS Pro, or PostGIS/QGIS depending on what tool works best. Sure I'm still copying stuff to new tables to reorder fields, but if I do that while writing spatial SQL in PostGIS, I can complete a geoprocessing step or two during each table copy for my trouble.
It's good to have choices, although I'm a little bit surprised to see how very slowly ArcMap is fading into ArcGIS Pro.
Back in the day, ArcINFO 7 went out in a flash for me, but ArcView GIS 3 stayed around sort of like this.
It's an aside from the ArcGIS Idea being discussed here, but my observation as a longtime user of ARC/INFO (since before ARCEDIT and AML existed), an ArcGIS 8.0 Technology Preview participant, and a national technical support manager of an Esri International Distributor during the MapObjects/SDE/ArcView/ArcInfo Workstation to ArcGIS cutover was that most large ARC/INFO sites did not cutover to ArcGIS until most feature equivalency was achieved and that took until ArcGIS 9.2 about 6 years later.
The effort in replacing the architecture of ArcGIS Desktop 10.x by that of ArcGIS Pro is no less trivial, and I think is going well. Both architectural replacements have involved massive platforms, and I think the effort involved on many fronts should not be underestimated.
I have preferred working in ArcGIS Pro rather than ArcMap for the last 2-3 years despite wishing that both had Arc: PULLITEMS available.
Brian, your perspective largely matches mine. For me, these types of limitations have been great at getting me into either alternative solutions like PostGIS/QGIS, to the overall greater detriment of my opinion and usage of the ESRI stack, or forced me to do more re-useable scripting of UI-laborious processes.
Disability to re-order fields isn't the end of the world, but the lack of any solution from ESRI in the face of this level of demand for a feature, even in a limited implementation, is the problem. If this type of change request went into the QGIS stream, we would probably see something in the following months, nota decade(or ever in this case). Given the cost differential between platforms, that'sutterlyembarrassing.
With the change from ArcView 3 to 8, there were significant benefits to migrating once the bugs were ironed out of 8 (alongprocess as I recall, not until 8.2 or 8.3 was itfairly universallyadopted in my world), as well as a new data format (GDB) with lots of new capabilities and less limitations than shapefiles/coverages. With Pro, there's just not much good reasons for users that haven't been forced into ArcGIS Online to even open it unless they are naturally early-adopters. Until there is a forcing through licensing (a thing ESRI tried), compatibility, or a wider need to use ESRI's online services in a significant way Desktop cannot, I don't see Pro really coming on like the ESRI hype seems to want.
All I want to do is create a new field and put it next to another similar field further up in the fields view. This seems like a basic feature that should have been incorporated into the product from the beginning. Being able to re-arrange field order is a key feature in organizing any data table...no need to "consider" this feature - get it done
This is not a convenience or nice-to-have, it is often a necessity that needs workarounds that take extra time and effort to achieve. Looking forward to seeing this in ArcGIS Pro in the future.
