Difference between revisions of "User talk:Apex-LW'21"

From SgWiki
Jump to navigation Jump to search
Line 331: Line 331:


--Scania 01:51, 5 September 2016 (SGT)
--Scania 01:51, 5 September 2016 (SGT)
I'm alright with this idea, since this looks to me that it's more organised than the current format.--[[User:Apex-LW'21|Apex-LW'21]] ([[User talk:Apex-LW'21|talk]]) 21:16, 5 September 2016 (SGT)

Revision as of 21:16, 5 September 2016

Welcome to my talk page!

Please post on my user talk page (not my user page) if you want me to delete any outdated / unrelated articles or any unused images existed in sgWiki. Also, please provide the links to the uploaded images (if any) when requesting to delete the articles.

I will review the pages first before I will delete, but however, should any of the pages that requires cleanup or is sufficiently related, it will not be deleted, unless there is a reason to believe that the article is the above-mentioned. Pages (including its talk page of a current page) which are blanked out, unanswered or remained for a certain prolonged period will be deleted in the event of any routine house-keeping or cleanup in sgWiki.

If your account is mistakenly banned due to posting of false or unrelated information, etc, please ask the administrator who had originally banned you by writing on the user's talk page to appeal, unless if you are mistakenly banned by me. If an information is mistakenly marked as false statement, you had to clarify with the administrator and provide justification that the information is true and accurate. However, the decision will be made by the administrator and the decision of the appeal is final, after the investigation is complete.

Do note that the successful appeal of the ban (only for those accounts banned by me) can only be done once. Once the ban appeal is successful, you are to comply with the sgWiki Guidelines. Appeals for repeated bans will not be considered.

The appeal procedures will also apply to the warning points imposed to the account.

If any articles or uploaded photos are deleted by mistake, please use my talk page to appeal. Please note that any deleted articles/photos will be subjected to further review and decision. This appeal only applies to articles/photos that were previously deleted by me. If you wish to appeal on any articles/photos that were previously existed in sgWiki that were deleted by any other administrators, please write on the respective talk pages.

Any accounts that are in severe violation of the rules as stated on the sgWiki Guidebook will not be unbanned. Please ensure that all edits and articles are complied with the sgWiki Guidelines.

If your account is being affected by any Autoblock function caused by the user being blocked for spam advertising, etc, please use my talk page so that I can remove the Autoblock.

For any Captcha issues, please refer to the administrator 'Jason' by writing on his talk page.

For bus-related pages, if you find any mistakes in any pages (only those edited by me), please use my talk page to point out the mistakes and clarify with me. I will make the necessary corrections as soon as possible.

Summary of Issues

[Half-Resolved] Redundancy of Tower Transit Bus Deployment By Service

Supernutorcrazy has suggested that the pages for Tower Transit Bus Deployment by Services was redundant as lack of quality information.

SBS3602U suggested that we will wait for a period of time to see if the deployment will be stabilised if not the whole pages and subpages to be deleted.

Request for a dateline before the pages to be deleted.

Comments

Tower Transit deployments for the day is somehow irregular. But I found that the Enviros running on Service 106 are much stablised and certain Wrights on 78, 79 and 143 as well.

Also, I think we can change the title page as Bus Contracting Model Deployment by Service, since there would be Go Ahead coming next month.

--Apex-LW'21 (talk) 23:46, 9 August 2016 (SGT)

[Unsolved] Messy Headers and Format especially with a single model with multiple long headers

Supernutorcrazy had suggested to merged it to a single table with a new columns that represent the operator which operates it and include a sortable table to reduce the need of long headers as the operators who operates the buses may not get it in running order.

However, SBS3602U highlight that if we will to get rid of it and follows Volvo B9TL (Wright Eclipse Gemini 2) (Batch 4) By Registration, it will cause editor to scroll down pretty far and may causes mobile devices to crash while editing. The long section names etc was still messy.

In light of this, it is possible to semi-get rid of it, but limit the number of rows per table to about 200 and also retain certain element like not in running order. (Eg: SBS1Z – SBS23K; SBS3449X – SBS3482Z & SBS3487K – SBS3523P; SG5000E - SG5120S & SG5176G – SG5185E; SG5300P – SG5395R & SG5397K – SG5399E; SG5546Y – SG5555X)

Comments

This page is for experimental purposes. Since these buses would be transferred to the respective operators (such as Go Ahead next month) and some will remain on their respective incumbent operator, this page would be useful especially when those existing bus registration plates might be re-registered to the SG plate in the near future. So this page will be kept for now.

--Apex-LW'21 (talk) 23:46, 9 August 2016 (SGT)

Lay up buses in the existing lists

I have observed that lay up buses and buses that are missing but not laid up have been removed from the lists. While it doesn't matter for retiring buses, doing so for types of buses which are nowhere near retirement causes inconvenience for users who need to edit it when the buses are back from repairs/missing. It also causes inconvenience for users who have to check the lifespan expiry page for layup buses. I therefore suggest that layup buses be retained in the lists while only removing deregistered buses, especially when the pages do not have a link to the lifespan expiry page.

--Scania 16:08, 13 August 2016 (SGT)

BCM mess

Bus Deployments to be listed by packages w.e.f 1 Sept where BCM would complete transitioning and all 11 packages operated by SMRT and SBST would be under BCM (but still operated by the 2 operators).

Confirmed actions
1. Bus Deployments by Package to replace:

2. Bus Deployments to replace:

Proposed actions:
1. By SMB315C:
Spare Buses to replace:

Listed by packages as well.

Comments:

I would go with having individual Spare Buses pages for each operator as each package is not allocated with a fixed batch of Spare Buses (that would be atrocious.)

Spare buses will only be shuffled among the operator itself.

--SBS3602U (talk | contribs) 00:25, 22 August 2016 (SGT)

Mercedes-Benz O530 Citaro Batch issues

As for the Mercedes-Benz O530 Citaro Batch Identification Problem, I would suggest the SBS Transit Batch to change from Batch 1 --> Batch 2 etc. (Increment of Batch by 1), with SMRT Batch takes Batch 1 purely, as all buses under BCM will undergo "Refurbishment" with standardise interior fitting sooner or later, similar to the mock-up DD.

--Supernutorcrazy

For the Mercedes-Benz O530 Citaro mess, there is a need to clear the conflict as Bus Deployments by Service pages may look like this in the future:-

Service example (7 buses) Handicapped/disabled access

SMB136C SMB141L SMB188C
3 Mercedes-Benz O530 Citaro (1 Demonstrator / 1 Batch 1 / 1 Batch 2)

SG1691L SG1699R SBS6000L SBS6001J SBS6444P
5 Mercedes-Benz O530 Citaro (2 Batch 1 / 1 Batch 2 / 2 Batch 3)

And this of course doesn't make sense. There are 2 ways I could think of:-

I wouldn't recommend this as in the worst case scenario, these buses may be re-registered to the SG-prefix plate.

I would recommend this more, though it may take some time for the community to adjust to which pages they were in the past. To solve this problem, we could have notices above the pages informing visitors.

Opinions are welcome.

Regards.

--SBS3602U (talk) 15:00, 14 August 2016 (SGT)

Citaro suggestion
It could be as such:
Citaro (SMRT spec)
Citaro (SBS Transit Spec B1)
Citaro (SBS Transit Spec B1)
Citaro (SBS Transit Spec B3)
--Scania 17:22, 15 August 2016 (SGT)

With regards to the Citaros, I think that the title naming should remain as such, like Batch 1, Batch 2, Batch 3 etc.
For the case of the classification of an example of a Citaro with SBST specification Batch 1, this can be applied to the respective "Specifications" table of the bus deployment list. This can distinguish the specifications on the table itself rather than placing it as a title of a bus deployment page list.

--Apex-LW'21 (talk) 21:09, 15 August 2016 (SGT)

However, the problem with the conflicting Batch names still occur and bus deployments by service pages may face problems should a service have both SMRT-spec and SBS-spec Citaros like in the example above (will just put it here for convenience)

Service example (8 buses) Handicapped/disabled access

SMB136C SMB141L SMB188C
3 Mercedes-Benz O530 Citaro (1 Demonstrator / 1 Batch 1 / 1 Batch 2)

SG1691L SG1699R SBS6000L SBS6001J SBS6444P
5 Mercedes-Benz O530 Citaro (2 Batch 1 / 1 Batch 2 / 2 Batch 3)

Therefore, I feel that the page names still need to change.

--SBS3602U (talk | contribs) 22:48, 15 August 2016 (SGT)

For the case of that scenario as highlighted, may I suggest that the bus deployment pages of the respective Citaros be distinguished in terms of the specifications that every SBST/SMRT Citaros has it.

Which means for instance "Batch 1 (SBST spec)" for Citaros with Batch 1 SBS Transit specifications can be used as such.

--Apex-LW'21 (talk) 20:59, 16 August 2016 (SGT)


Re: Reply No. 4 [1]

I feel that it may look weird with SBS-spec / SMRT-spec included when it is listed in the Bus Deployments by Service pages:

Service example (8 buses) Handicapped/disabled access

SMB136C SMB141L SMB188C
3 Mercedes-Benz O530 Citaro (SMRT-Spec) (1 Demonstrator / 1 Batch 1 / 1 Batch 2)

SG1691L SG1699R SBS6000L SBS6001J SBS6444P
5 Mercedes-Benz O530 Citaro (SBST-Spec) (2 Batch 1 / 1 Batch 2 / 2 Batch 3)

Both solutions have their bad points. Hence, this is more of a preference issue.

  • Have SMRT-Spec/SBST-Spec in the page titles
    • May look weird as a page title itself and when listed in deployments by service pages as it is a little too long.
  • SMRT spec Citaros to use (Batch 1 & 2), SBST spec Citaros to use (Batch 3) (Batch 4) (Batch 5)
    • May cause confusion with the visitors and editors.

Of course, I'm not one to decide how the wiki should turn out (the way I like it) and just stating my point of view on the suggestions. As this issue is more towards preferences, I'd like it if we could get more opinions from the community or the editors here :)

Regards.
--SBS3602U (talk | contribs) 16:45, 18 August 2016 (SGT)

Question of reference about overall Batches 2 & 3 of all Citaros.

Greetings.

I have taken note of the ongoing discussions with some of the more actively contributing users in here, with regards to the labeling of Citaros. While I currently do not have any ideas for that, but I would like to pose a question of reference to you all.

While SMB149R to SMB188C was classified as "SMRT - Batch 2" which also means that it is the overall second batch of the Citaros, and that SBS6000L to SBS6285G are classified as "Batch 3" (overall in the suggestion of the other users), in actual, SBS6000L was registered much earlier in April 2011 as compared to SMB149R which was registered in October 2011. In my view, there is a confusion as to whether there was a specific rule; in which the first bus of a particular batch (in this case the SBST's Batch 1) had to be registered earlier, to constitute an overall earlier batch than another batch (the SMRT's Batch 2) which first bus was registered later? If there is such a rule, shouldn't SBS6000L to SBS6285G be labelled as overall Batch 2 and SMB149R to SMB188C be labelled as overall Batch 3?

--ASA1234 (talk) 20:53, 21 August 2016 (SGT)

Reply

In terms of specifications and the date of the first roll-out, I would say that for SBS6000L to SBS6285G & SBS6300X to SBS6341C, it would be labelled as Batch 2 and SMB149R to SMB188C would be labelled as Batch 3 in overall and so on, although the Batch 3 Citaros (SMRT Batch 2) were entirely rolled out, while the Batch 2 Citaros (SBST Batch 1) were ongoing rollout.

--Apex-LW'21 (talk) 05:28, 23 August 2016 (SGT)

Request: Coordinating history of buses page(s)

Hi, may I suggest that the various separate pages on the history of buses be merged, such that they are no longer discriminated by bus operator? Unlike the bus deployment page where the operator must be distinctively differentiated, the bus history page does not need its articles to be separated as such. This is also onsidering the onset of GCM, which makes continuously switching between history pages irritating (e.g. service 82), and makes finding a specific service difficult from the main page (when there are so many operators).

One way to still show the bus operator of that particular service would be to insert a long thin coloured column to the left of each service's table, for example deep purple for SBST, red for SMRT, green for TTS and pink for GAS, such that every time the service changes hands, it would be clearly reflected. The header of the service can still bear the colour matching its current operator's. This removes the need to have separate pages, so a common and tabulated article page for "2-20", "161-180", etc would suffice.

Dragomir7 (talk) 11:39, 22 August 2016 (SGT)

Reply

There are already plans to revamp the entire history of bus service pages that will combine all of its history of bus services together, from the past to the current operator.

Hence, the top headings which denotes the current operator and those no longer in operation (withdrawn or under that operator), will no longer be necessary as there will be a new table column for that.

--Apex-LW'21 (talk) 05:38, 23 August 2016 (SGT)

Not exactly. I'm not sure what you have in mind, but I did a variation on the current version (on services 81-83, 96 and 97) in my user sandbox, with some deliberate syntax inconsistencies for variation. Are you fine with that? Or you could propose changes or another sample version and we'll work towards that. Dragomir7 (talk) 10:16, 23 August 2016 (SGT)

Reply No. 2

Hi Dragomir7,
For its legend, the only thing is that we need to separate the preceding and current operators out through the years. You can't just put a merged formatting of the operators i.e. SBS/SBS Transit from 1971 to 2016 or TIBS/SMRT from 1983 to 2016 as this will confuse users.

For instance,
STC (1971)
ABC/ABS/UBC (1971 - 1973)
SBS (1973 - 2001)
TIBS (1983 - 2004)

SBS Transit (2001 - current)
SMRT Buses (2004 - current)
Tower Transit (2016 - current)
Go-Ahead (2016 - current)

The 'Operator' column, should be included, together with the bus operator logo on it.

Update: I have just revamped History of Punggol Feeder Services for your reference and I will just stick to the sgWiki standardised table formatting instead, rather than a separate formatting. The colour headers for each table will be default gray. So, in that case, I will slowly implement this across all history of bus services article.

This will generally give a clear idea on how these revamped pages will look like after another revamp of the articles.

--Apex-LW'21 (talk) 05:54, 24 August 2016 (SGT)

I like the idea of merger, removing the need for referring to multiple pages. However, I would like to feedback about the use of logos and the colour. Some of the older companies such as STC do not have proper logos, hence, I would suggest we use some other form of indication for operators such as coloured texts.
For the colouring of headers, grey would be misleading as they were used to indicate a change that is not effective currently. I would suggest using Blue for currently effective services and Gray for withdrawn services.
--SBS3602U (talk | contribs) 10:24, 24 August 2016 (SGT)
The problem with using logos, especially for all twenty services on one page, is that it would inflate the page size and make loading the page unnecessarily time-consuming. And also like SBS3602U pointed out above, the older operators don't have logos. Either we could simply list all the logos at the legend section at the start of the page, or just have a thorough one on the main bus history page, since the individual history pages all branch from it. After which we can use some other text form to represent the operator on individual pages. If there's a need to distinct between the earlier operators, we could consider using shades of either orange/yellow or cyan/blue/indigo (with just minor variations) before transiting to SBS violet (?) and SBST purple. TIBS can use beige and SMRT can keep with red.
As for the header, I also agree that it would be best to have a distinction between current and withdrawn services. A colour representing the current operator is my preference, but otherwise a neutral colour would be fine; blue is okay as long as it is a comfortable shade and not too jarring (so FF0000 is probably out).
Just my take. Dragomir7 (talk) 16:57, 24 August 2016 (SGT)

Reply

SBS3602U: As STC, ABS, ABC and UBC does not have a proper logo, I can just place in the text of the respective bus companies without the proper logos. However, as for SBS and TIBS including the SSB that used to run CSS services, we can use the logo as it is available on the Internet.

Dragomir7: I noted your suggestions to that. However, in sgWiki, we choose to standardise table on every pages, like how the bus deployment presents its information into a standardised table with proper formatting. Indicating bus operators as colours alone or adding a new column just for the colour would not be (or I must say, partially) be a good idea to improve the History of Bus Services articles.

--Apex-LW'21 (talk) 20:42, 25 August 2016 (SGT)

Hmmm. I have no comment to that now. But I do want to say that neither the bus deployment nor the bus fleet sections actively employ the use of bus operator logos. Hence in that sense I hope you can understand my hesitation to use them. Dragomir7 (talk) 16:01, 26 August 2016 (SGT)

Then in that case, I can just show the name of the bus operator, along with the corporate colours on its table background colour.
--Apex-LW'21 (talk) 15:30, 28 August 2016 (SGT)

Wrights batch 4 for GA tables

Hi,

Since the buses are now owned by LTA, and are transferred to GA now, the type of purchase does not matter now. Indeed, it is already the case for the SBS SG plate buses for the Wrights and Citaro pages, where the BSEP range is consolidated together with the non BSEP range (BSEP 51xx, 55xx, Non BSEP, 53xx, 54xx), for these two pages, due to the large amount of tables, it is good if we are consistent in following the SBS style of tables (SBS plate one table, SG plate one table), what I suggest is that, if the numbers are small enough after the handover, we could combine the SBS regos into one table.

Moving forward, because of the GCM, the type of purchase doesn't really matter anymore if the buses are owned by LTA, although for older buses (eg Batch 1-3 Wrights) owned by SBS/SMRT, we should keep those models' pages as it is.

This message was my own comment copied from a conversation with another user.

--Scania 17:12, 22 August 2016 (SGT)

Reply

I would still prefer the current layout for the Wright Batch 4 DDs deployment listing.

However, since the existing SBST Wright Batch 4 DDs which would be given away to Go-Ahead next month, what I can suggest is that having SBS and SG registration plate is another way. For that, there would be an additional column for its current operators where these buses are deployed.

--Apex-LW'21 (talk)

Clarification of idea

I would like to clarify what I have meant by using these tables:

SBS Transit

SBS1234A-SBS1235B

Registration no. Service Advertisement
Table will contain all BSEP buses + buses LTA purchased from SBS (for SBS plate buses)

ie Double digits + 34xx/35xx combined into one table

SG1234C-SG1235D

Registration no. Service Advertisement
Table already contains all BSEP + GCM non BSEP buses

Then for the Go Ahead section:

Go-Ahead

SBS1234A-SBS1235B

Registration no. Service Advertisement
Table will contain all buses transferred, ie all BSEP buses + buses LTA purchased from SBS (for SBS plate buses)

ie Double digits + 34xx/35xx combined into one table

SG1234C-SG1235D

Registration no. Service Advertisement
Table already contains all GCM buses

Basically, combining the SBS regos into one table each for SBS and Go Ahead, which another table each for SG plate buses.

I would propose starting the changes for Go Ahead first (in fact as soon as the regos of transferred buses can be verified) and for that of SBS to be done after the Pasir Ris handover.

--Scania 01:51, 5 September 2016 (SGT)

I'm alright with this idea, since this looks to me that it's more organised than the current format.--Apex-LW'21 (talk) 21:16, 5 September 2016 (SGT)

Retrieved from "https://sgwiki.com/index.php?title=User_talk:Apex-LW%2721&oldid=356566"