Jump to content

Talk:List of iPhone models

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia


[edit]

During a lengthy and arduous debate with @YannickFran, it was brought up that the iPhone article is inconsistent with other hardware articles such as Google Pixel and List of iPad models.

Hence, I propose changing the summary table as shown here.

Also, to make it easier on the eyes, I suggest switching to the iPad models article's color scheme. Cnscrptr (talk) 23:41, 14 September 2024 (UTC)[reply]

If nothing else, I'd strongly suggest that if this isn't adopted, that the colors still are updated to this color scheme. Especially the current green and blue are problematic from a readability/accessibility stand-point. As a matter of fact, I'd say that this specific change doesn't need discussion.
Having said that, I'd say this is an improvement, one that also helps address @GhostInTheMachine's request above this discussion. The only real notes about the content of the table I'd have is whether we really need an age for all these dates. It seems a bit redundant, but I don't have strong feeling to it either way. And also, I still wouldn't call the column "Unsupported", that's a bit to definitive for something we don't really know for a fact (again, iOS 9 shenanigans), I4d go with "Latest release".
Beyond that just a few technical notes: first off the dates in the "Announced" column are written in a shortened notation, especially if the ages are removed, I feel like these can be written in their long format. Second, for displaying the latest iOS 12, 15 and 16 dates, we have the templates at Template:Current iOS (specifically the short versions) that can be used instead of hardcoding the current version and having to come back every time they might be updated in the future. Third, to not give the SE rows extra height, I feel like its better to put their generation on the same line as the name, if that is too long, I think it is fine to shorten "2nd generation" to just "2nd" for example. And fourth; whenever a line break is used, I'd suggest using the HTML br-tag. This assures that the second line isn't wrapped in a paragraph tag and doesn't create the awkward height as seen in the iPhone 4 and 6 lines (and the SE models, but that would be fixed with point 3 if that's adopted). YannickFran (talk) 06:44, 15 September 2024 (UTC)[reply]
If editors don't respond within several days, should we assume that they are inactive and implement this proposal? Cnscrptr (talk) 02:36, 16 September 2024 (UTC)[reply]
Please can you summarise the nature of the change — GhostInTheMachine talk to me 14:44, 16 September 2024 (UTC)[reply]
Alright, here's a summary:
- The table will be split in the following columns: Generation, Model, Announced, Release (sub: OS and Release Date), Discontinued, Unsupported (sub: Last OS and release date), and Lifespan
- The end of support will be considered the moment a device stopped receiving updates entirely (e.g., the iPhone 4S was unsupported on July 22, 2019 with iOS 9.3.6).
- To improve visibility and make it easier on the eyes, the color scheme will be changed to that of the List of iPad models
- Additional Proposal: Abbreviated dates (e.g., Sep 9, 2024) will be used to save bytes and make reading easier and faster. Cnscrptr (talk) 16:01, 16 September 2024 (UTC)[reply]
Ta. Drop the Lifespan column too please — GhostInTheMachine talk to me 16:03, 16 September 2024 (UTC)[reply]
We can discuss this later.
Also, look at my sandbox to see the changes so far. Cnscrptr (talk) 16:06, 16 September 2024 (UTC)[reply]
Alright, the proposal has been implemented. There are just a few things to discuss, including but not limited to
- Drop the Lifespan Column (suggested by @GhostInTheMachine)
- Abbreviate the months (suggested by @Cnscrptr) or lengthen them (suggested by @YannickFran) Cnscrptr (talk) 16:24, 16 September 2024 (UTC)[reply]
Should we drop the Lifespan Column? (suggested by @GhostInTheMachine) Cnscrptr (talk) 16:30, 16 September 2024 (UTC)[reply]
No, the lifespan column should remain. YannickFran (talk) 16:44, 16 September 2024 (UTC)[reply]
Oppose. Removing the lifespan columns is more trouble than it's worth, not to mention it's a handy piece of information to have. Cnscrptr (talk) 17:06, 16 September 2024 (UTC)[reply]
more trouble than it's worth? Not at all difficult, I can easily do it for you — GhostInTheMachine talk to me 12:33, 18 September 2024 (UTC)[reply]
Should we abbreviate the months (suggested by @Cnscrptr) or lengthen them (suggested by @YannickFran)? Cnscrptr (talk) 16:30, 16 September 2024 (UTC)[reply]
For the record, I don't care much for whether or not the months are abbreviated (although it is more common for them to not be and given the number of columns I don't see a reason to abbreviate), but the date notation should be consistent between columns. YannickFran (talk) 16:43, 16 September 2024 (UTC)[reply]
Abbreviate. It saves bytes, although readability does not improve by much. This should also be implemented in other list articles to make it easier on Wikipedia's servers. Cnscrptr (talk) 17:07, 16 September 2024 (UTC)[reply]
"It saves bytes" really isn't a concern that should dictate how we do anything and it is in general neglectable. YannickFran (talk) 19:25, 16 September 2024 (UTC)[reply]
Actually, I just removed sortability and as a result of that could do away with the "Announce" columns use of a sortable template, which most appropriately was replaced with Template:Start date, which doesn't seem to allow to abbreviate or pick any notation at all, so this may be the universal agreed up notation for Wikipedia. This is me just using the template, not trying to push this opinion through. There is just not really another way to do this (unless we go for just plain hardcoding the dates). YannickFran (talk) 19:41, 16 September 2024 (UTC)[reply]
Sounds good to me. Cnscrptr (talk) 21:54, 16 September 2024 (UTC)[reply]
About the unsupported status.
Users it may concern: @YannickFran, @Cnscrptr
As established before, support means a device is receiving updates (regardless of which); unsupported devices are no longer receiving any software updates. Not to mention labeling the iPhone 6S/7/etc. as unsupported contradicts the dates and status placed. Cnscrptr (talk) 17:14, 16 September 2024 (UTC)[reply]
@YannickFran, please elaborate Cnscrptr (talk) 17:40, 16 September 2024 (UTC)[reply]
Please don't constantly tag me (I get why and its fine, not mad or something). I've got this page on my watch list. I'll respond when I get to it. :)
Having said that, I've updated the descriptions to the old ones to better explain them, maybe that's better and more clear on what it is. If so, we should roll these changes out to other articles like iPad. YannickFran (talk) 19:23, 16 September 2024 (UTC)[reply]

Sticky headers for remaining tables

[edit]

@Evelyn Harthbrooke: I appreciate your concerns about making windows (of tables) smaller. However, the <div> prevents {{sticky header}} and {{sticky table start}} from working, and headers are harder to remember, especially for casual readers. To make row and column headers sticky, I had to make the windows smaller, especially for smartphones and tablets. To address concerns about height of windows, how about more than 75vh, which template instructions have normally discouraged? George Ho (talk) 02:08, 23 September 2024 (UTC)[reply]

These tables don't need to be sticky. If it's going to destroy the usability of the tables, sticky headers should be avoided, especially for tables like the ones used here. - Evelyn Harthbrooke (leave a message · contributions) 04:43, 23 September 2024 (UTC)[reply]
I should say however that sticky headers being used on smaller, less complicated tables is fine. But adding sticky headers to complicated tables such as the ones detailing iPhone specs should be avoided, especially if the overall usability of the tables will be compromised, and especially as sticky headers aren't that important. - Evelyn Harthbrooke (leave a message · contributions) 04:56, 23 September 2024 (UTC)[reply]
sticky headers aren't that important. Can you grasp the details about specific models without sticky headers? Do you think others can? Also, I've yet to see instructions discouraging use of sticky headers in complex tables, especially with a class sticky-table-head and MOS:TABLE not mentioning sticky headers yet. At least H:Table/A#Tables with sticky headers guides readers how to code sticky headers. George Ho (talk) 06:41, 23 September 2024 (UTC)[reply]
Yes, yes I can, because the table is easy to understand. All current models are listed first in the table. And yes, I believe other readers can understand the details of the models without sticky headers. Readers don't forget things that quickly. You'd have to read the model name and instantly forget it to not know what you are looking at. And I'm talking about sticky headers being used in long tables that require a div to avoid overflow, because restraining them to a specific size (and significantly increasing scrolling) causes a great number of usability issues, especially when the reader can barely see any details without scrolling. - Evelyn Harthbrooke (leave a message · contributions) 07:16, 23 September 2024 (UTC)[reply]
You'd have to read the model name and instantly forget it to not know what you are looking at. At a table this long? What if a casual, non-regular reader goes to this list and reads one of row headers (i.e. one specific, e.g. a detail of a rear camera) first all the way down and then scrolls right to see differences among various models? What about the other casual, non-regular reader who first goes to an older yet currently supported model and scrolls down? Are we thinking primarily readers who visit the project regularly or readers who just wanna visit via Google search or...? George Ho (talk) 11:39, 23 September 2024 (UTC)[reply]
Like I said. If the sticky headers do more harm than good for the usability of the templates, they should be avoided for the sake of everyone. Nobody wants to scroll forever down a tiny window, especially for a table. - Evelyn Harthbrooke (leave a message · contributions) 21:58, 23 September 2024 (UTC)[reply]

Removing the obsolete/vintage/unsupported distinction

[edit]

Decided to be BOLD. My latest edit removes the distinction being made between a device being obsolete, vintage and unsupported and instead opts to call these devices "unsupported". These data points previously relied on a definition given by Apple, which we here. However, Apple's seemingly arbitrary way of assigning these designations to devices has only led to us having to make notes explaining away why a device that shouldn't be vintage yet is, why a devices that should have been marked obsolete long ago isn't, and why a specific color or storage size of a device is marked vintage or obsolete and no other model is. Of the 10 notes on this page, 9 are dedicated to fixing this (and leaving more discrepancies unexplained).

For this reason, I've removed the distinction and recolored the "Discontinued and unsupported" color in the legend to match the default table heading color so whenever a device reaches this status, we simply can remove the styling (and Wikipedia's dark mode is happy too). This edit also removes the latest iOS coloring and the coloring of the "Discontinued date" and "Unsupported date" rows in the comparison tables as this is simply redundant and just more to maintain/overlook. YannickFran (talk) 19:22, 3 January 2025 (UTC)[reply]

That's a good idea especially since I don't think we need to update it indefinitely. Stephen"Zap" (talk) 14:52, 4 January 2025 (UTC)[reply]
I concur. The obsolete and vintage categories concern repairs and hardware support more than article standards, not to mention what Stephen"Zap" said. Cnscrptr (talk) 18:25, 7 February 2025 (UTC)[reply]

Reorganize article

[edit]

Whether or not I'll spend time actually implementing it is a bridge to cross later, but I'd rather do it without being reverted.

Right now, the article splits the comparison tables between "Unsupported 32 bit", "Unsupported 64 bit from 2013-2017", "Supported without Apple Intelligence" and "Supported with Apple Intelligence". We're dividing devices based on a rather arbitrary change in their capability that is bound to result eventually in one side of the split being much larger than the other (both for the 32 bit and for the Apple Intelligence splits). All in all, the move to 32 bit isn't that notable and seems mostly picked because at the time, it divided the table roughly in 2, but that is no longer the case.

Having devices move from one table to the next just because a certain date passes also seems a bit to arbitrary, especially since we don't actually know when Apple stops providing support for an older version of iOS (currently the tables assume if it isn't the latest major it is unsupported, but that isn't really the case).

So I propose we need to divide these devices differently. One possibility is to divide by generation (e.g. Comparison of Samsung Galaxy S smartphones), an issue with that is that for pre-iPhone X generations, we'd probably want to combine multiple.

However, the way I think makes the most sense is to simply split by premium, regular and entry level similar to how the timeline at the bottom does it. It makes more sense to me to compare the various SE devices with one another, and the various Pro devices, rather than having the tables flip-flop between the type of device that is being compared. Further more, given the lack of differences between a base model and its Plus/Max variant, it might just make more sense to combine them and denote any difference if they are applicable. For the vast majority, this is only relevant for device sizes, the only exception being the iPhone 12 Pro and 15 Pro for their cameras. For the regular line, this would of course still leave a wide array of devices (18 in total), here it would make most sense to just split iPhone 1 through 8 and iPhone XR through the current iPhone 16). From there on out, it may make most sense to just split every 10th iPhone (iPhone 20, 30, etc.) for all lines. YannickFran (talk) 16:19, 5 January 2025 (UTC)[reply]

I partially reorganized the article by making "Supported" and "Unsupported" subheadings with smaller subheadings for the other distinctions.
So far, I agree with you in some aspects.
The 64-bit CPU distinction should be dropped. An unsupported device is an unsupported device. Furthermore, the switch to 64-bit happened long ago with the iPhone 5S, which has been unsupported for a long time.
The distinction between regular and plus/max models is mostly superfluous and can be resolved with delineating the differences within the columns. Cnscrptr (talk) 18:23, 7 February 2025 (UTC)[reply]
I also think we can move the "Apple intelligence" row to the top for relevance and compensation for the removal of the Apple intelligence distinction in subheaders. Cnscrptr (talk) 18:28, 7 February 2025 (UTC)[reply]

Colorblind-friendly palette for legend

[edit]

For ease of visibility for all groups in Wikipedia, particularly those affected by colorblindness, we should develop a colorblind-friendly palette that takes into account all types (red-green colorblindness in particular, the most common one). My recommendations:

  • Differences in brightness to adjust for achromatopsia
  • A color scheme that is palatable to at least the majority of colorblind people by making colors as distinguishable as possible for all groups.

Wikipedia has been dedicated to colorblind-friendliness, encouraging red-blue over red-green schemes. This dedication to accessibility makes articles easier to read for all readers.

-
So far, I've implemented a red-green colorblind-friendly palette (green to blue) and have modified the "Upcoming" category (blue to purple to red) for tritanopes. Cnscrptr (talk) 18:12, 7 February 2025 (UTC)[reply]

P.S. I haven't yet implemented the color scheme in other articles amid the discussion of a potentially better colorblind-friendly palette. Cnscrptr (talk) 18:29, 7 February 2025 (UTC)[reply]
When has Wikipedia encouraged red-blue over red-green schemes? Even the accessibility guidelines don't talk about this at all, but rather discourage the use of colors as the only way information is conveyed and to assure high contrast (MOS:COLORS). And this is exactly what the table does; for those with color blindness, the table still conveys that information. But colors themselves have meaning (both in general, and in this case specifically), and in this specific instance that meaning is wide-spread across Wikipedia in various articles and various templates. Changing the colors around just moves the problem from one type of color blindness to the next. Red-green color blindness is the most common color blindness, but if the goal is to target the largest audience (which frankly; we should) then targeting no color blindness is the way to go. The table is fully accessible without the colors, they are just an aid. Making the coloring system confusing (contradictory to how they are used elsewhere and just the general meaning of colors (e.g. red means stop)) for 90% of the population isn't the solution here. Ideally Wikipedia has options to deal with this itself, but furthermore, accessibility tools outside Wikipedia can already help out with color blindness. We should absolutely accommodate color blindness and other accessibility issues, but that should not impede on the usability of Wikipedia for other users. YannickFran (talk) 20:05, 7 February 2025 (UTC)[reply]
When has Wikipedia encouraged red-blue over red-green schemes? Even the accessibility guidelines don't talk about this at all, but rather discourage the use of colors as the only way information is conveyed and to assure high contrast (MOS:COLORS).
The entirety of Wikipedia talk:WikiProject Weather/Colour discussions held a years-long debate trying to create a colorblind-friendly palate for the Saffir Simpson Scale. Similar standards have been applied in the maps of LGBTQ rights by country and The Economist Democracy Index.
This is a precedent rather than a guideline, although it is one that we should follow.
Changing the colors around just moves the problem from one type of color blindness to the next.
This is exactly why this discussion was opened; to develop a color scheme that is usable by most colorblind and non-colorblind readers, if not all readers. For now, targeting red-green colorblindness is a step forward (although the change from purple to red should be reviewed).
then targeting no color blindness is the way to go
At the expense of other readers when the color system can be improved.
Making the coloring system confusing
I admit the color red for upcoming wasn't a good choice, but what color should we use for it? (For now, I'll revert to purple since it still helps red-green colorblindness)
You pointed out purple was problematic (which it was for tritanopes) when it can also symbolize something new for non-colorblind users.
Likewise, blue has often substituted green in various cases and can likewise mean good/positive/recent.
Perhaps the problem you find is how links are also blue and purple.
For now, we should keep these colors (blue and purple) since they are in no way problematic.
----
The goal of this discussion is to find a colorblind-friendly palate for the legend to make it accessible to the most users possible. I recommend keeping the "neutral, yellow, blue, purple" scheme for now, although reverting to the previous scheme is fine by discretion while this discussion takes place. Cnscrptr (talk) 22:10, 7 February 2025 (UTC)[reply]
The situation for the colors in the Weather project, where the color was the only way a data point was distinguished on a map, is different from a situation where the color is substituted by the data in a table. I absolutely agree with the discussion held there however, that situation and the reasons for it simply don't apply here. The accessibility of the table is already handled by its contents, the colors are just to help visualize it, they aren't the primary way the information they hold is conveyed to the reader. And again; these colors are widely used across Wikipedia, and people will rightfully expect their meaning to be (at least roughly) the same across articles and for that meaning to be logical and consistent.
This is in my opinion a discussion that should be held higher up so it can be discussed with more people and impact all relevant pages if/when a consensus is reached rather than on a talk page of a comparison article. YannickFran (talk) 23:31, 7 February 2025 (UTC)[reply]
Retrieved from "http://en.wiki.x.io/w/index.php?title=Talk:List_of_iPhone_models&oldid=1274692395"