Talk:List of iPhone models

"List of iPhone and iPod Touch models" listed at Redirects for discussion

The redirect List of iPhone and iPod Touch models has been listed at redirects for discussion to determine whether its use and function meets the redirect guidelines. Readers of this page are welcome to comment on this redirect at Wikipedia:Redirects for discussion/Log/2023 May 3 § List of iPhone and iPod Touch models until a consensus is reached. - CHAMPION ^{(talk) (contributions) (logs)} 02:07, 3 May 2023 (UTC)

iPhone 5SE

I had an iPhone 5 SE. Can't find it on this list? 180.150.112.55 (talk) 05:29, 17 November 2023 (UTC)

You are either referring to the iPhone 5S or the iPhone SE 1st gen 2401:7400:C80B:A7C7:10C3:6949:AF3:EFFA (talk) 00:38, 31 January 2024 (UTC)

Trim the Release dates table

I propose to delete the Months supported and Months supported after discontinuation columns. As the table has the raw dates, the month counts are pointless — GhostInTheMachine ^{talk to me} 17:25, 17 June 2024 (UTC)

Oppose. It's nice to know how long a device has been supported at a first glance, not to mention it is an interesting fact. INFIYNJTE (talk) 20:37, 1 August 2024 (UTC)

Trim and Reformat the Summary Table to improve visibility and match other articles

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. INFIYNJTE (talk) 23:41, 14 September 2024 (UTC)

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)

If editors don't respond within several days, should we assume that they are inactive and implement this proposal? INFIYNJTE (talk) 02:36, 16 September 2024 (UTC)

Please can you summarise the nature of the change — GhostInTheMachine ^{talk to me} 14:44, 16 September 2024 (UTC)

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. INFIYNJTE (talk) 16:01, 16 September 2024 (UTC)

Ta. Drop the Lifespan column too please — GhostInTheMachine ^{talk to me} 16:03, 16 September 2024 (UTC)

We can discuss this later.

Also, look at my sandbox to see the changes so far. INFIYNJTE (talk) 16:06, 16 September 2024 (UTC)

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 @INFIYNJTE) or lengthen them (suggested by @YannickFran) INFIYNJTE (talk) 16:24, 16 September 2024 (UTC)

Should we drop the Lifespan Column? (suggested by @GhostInTheMachine) INFIYNJTE (talk) 16:30, 16 September 2024 (UTC)

No, the lifespan column should remain. YannickFran (talk) 16:44, 16 September 2024 (UTC)

Oppose. Removing the lifespan columns is more trouble than it's worth, not to mention it's a handy piece of information to have. INFIYNJTE (talk) 17:06, 16 September 2024 (UTC)

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)

Should we abbreviate the months (suggested by @INFIYNJTE) or lengthen them (suggested by @YannickFran)? INFIYNJTE (talk) 16:30, 16 September 2024 (UTC)

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)

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. INFIYNJTE (talk) 17:07, 16 September 2024 (UTC)

"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)

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)

Sounds good to me. INFIYNJTE (talk) 21:54, 16 September 2024 (UTC)

• All dates should be full length. Remove the age parts throughout — GhostInTheMachine ^{talk to me} 16:31, 16 September 2024 (UTC)

About the unsupported status.

Users it may concern: @YannickFran, @INFIYNJTE

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. INFIYNJTE (talk) 17:14, 16 September 2024 (UTC)

@YannickFran, please elaborate INFIYNJTE (talk) 17:40, 16 September 2024 (UTC)

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)

Sticky headers for remaining tables

@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)

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)

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)

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)

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)

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)

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)