Benefits of Retaining the Electoral College
It respects the Great Compromise between the states - The Great Compromise, meant to protect small states from getting overwhelmed by the larger ones, necessary to get them to agree to form the Union, extended not just to the legislative branch but the executive as well. By adding the equal number of senators to the number of congressmen to determine each state's electoral votes, small states were given additional weighting in the say they would have in choosing the President.
For example, one state A with twice as much population as B might have 6 representatives to B's 3. However, the number of electoral votes is not 6 to 3 or twice as much say but 8 to 5 due to the addition of the senators, resulting in just 1.6 times as much say, honoring the compromise. Switching to a popular vote would eliminate that weighing benefit, as state A would have roughly twice as many voters as B and hence twice as much say.
This benefit given to the small states has shrunk by about a third since the country was formed. In the First Congress there were 68 congressmen and 26 senators generating a total of 94 electoral votes, so that a state's population was only a 68/94 = 72.3% factor of its say. Since the number of congressmen was fixed at 435, population now provides 435 / 535 (leaving out D.C.'s 3 electoral votes which aren't based on representation) or 81.3% of the weighting.
States are better protected from voter irregularities occurring in other states - With the Electoral College, any ballot-box stuffing done by one state does not limit the say of others. Take one state with say 10 electoral votes, for example, they could have three, five, ten million falsified ballots for a candidate, they can go to town, it wouldn't matter, only that state's 10 electoral votes would be corrupted. Pennsylvania (20 votes), Iowa (6), Arizona (11), etc., would still have their say and their respective weighting. If we switched to a popular vote, those invalid votes would count to the national total, harming the say of states that run their elections more cleanly. In general:
With a national vote election, states which do a better job ensuring valid voting (photo ID, checking to make sure voter registrants are US citizens, alive, etc.) would lose say over states that tend to look the other way in such matters.
Conversely, because we use an Electoral College, there is much less incentive for ballot-box stuffing as it doesn't buy one party-dominant states tempted to engage in such activities anything. It results in cleaner elections, and hence a cleaner society, nationwide.
A national vote would encourage a race to the bottom in granting suffrage ("State A is now allowing their green card holders to vote, so we should also lest we lose our say...", "State B is now allowing 16 year olds to vote...", etc.)
Close elections are much easier to resolve - The 2000 election between Bush and Gore took about one month to resolve but the focus thankfully was just with Florida and its then-25 electoral votes. Because the Electoral College was all that mattered, the other 49 states could be ignored, 20 inaccurate votes in Idaho for example or 30 missed votes in California could be disregarded. However, if we had a tightly close popular vote election, then every precinct in every county in every state would be subject to re-examination, to grab 5 votes here and 10 votes there because they all count towards the national vote total, not a situation anyone would relish.
With the Electoral College, people are more likely to vote for a candidate based on his/her policies rather than on whether or not he/she has visited their state. - Voters in places like California and Tennessee where the outcome of the vote is not in doubt are perfectly fine with their candidate of choice never visiting their home state during the campaign. More than that, they don't actually want their candidate wasting time in their home states, instead wanting him or her to be in battleground states trying to win them over so their candidate can win. This provides a lot of relief to presidential candidates as it allows them to focus on visiting just 10-15 battleground states, a grueling enough task as it is.
With a national popular vote, however, it would still make sense to visit vote-rich states regardless of their leanings, causing many voters to get offended if their candidate does not visit them, and possibly switch votes as a result. So the Electoral College is more likely to result in voters casting votes based on the candidate's policies than whether they visited their state, good for the nation as a whole.
The Electoral College makes election night a lot more exciting to watch - A silly argument, but still true. With the Electoral College, viewers see a scoreboard of states that slowly get lit up in red and blue during the evening, for which viewers can celebrate or mourn each time a candidate wins or loses a state. With a national vote you're just waiting for a vote total at the very end, rather dull for all concerned. It would be similar to watching a football game in which all touchdowns and field goals are irrelevant but just the total yards gained within the 60 minutes of play determining the victor.
Finally, it should always be noted that a candidate who wins the popular vote and loses the electoral votes on an election based on the latter wouldn't necessarily have won the popular vote if it were based on the former, as the campaigning done--states visited, TV advertising strategy, issues chosen, voter turnout generated, etc.--is different under the two styles. A skilled candidate who can win with one set of rules quite frequently has the ability to win under another.
TightBlog: August 2016 update
I'm back to work, my summer sabbatical is now complete, so I won't have nearly as much time to spend on TightBlog. The release of TightBlog 1.0 was a mission accomplished for me (similar to my prior time off, which I spent releasing Roller 5.1.) I did get a few simplifications in this month though, removing four more Java source files and 2 JSPs.
I advertised the release of TightBlog 1.0 on the Apache Roller users mailing list and got some more traffic from Roller users who did not yet know of my fork.
I said last month that "talk is cheap" and refrained from mentioning what I'd like to get done. But cheap talk is sometimes still useful: For TightBlog 2.0, I'd like to finish up the REST API for the application, a few more screens still rely on server-side screen generation. Once done, so little Struts code will be remaining that I plan on pulling out the Struts library and replacing it with Struts MVC, whose libraries are already being used for the REST controllers. I hope to get a tag management page in for deleting, renaming, and adding tags. Thymeleaf in addition to or replacing Velocity for the blog templates may also be a good idea. I might remove the Planet functionality as it was seldom used in Roller and the effort spent maintaining it can perhaps better be spent enhancing the rest. Finally, a package renaming and restructuring, replacing the legacy org.apache.roller.* naming with a new org.tightblog.* or similar.
(I still need to convert *this* blog to TightBlog--awaiting the new OpenShift PAAS update before doing so, but maybe I'll switch to Digital Ocean instead...)
TightBlog: July 2016 Update
I started a new TightBlog 2.0 branch, with more modernizations and new functionality planned for it. I'd like to list what I have planned, but talk is cheap--let me code and as I am able to complete new features I'll announce them. Just yesterday, for example, I switched to Thymeleaf for email messaging in the 2.0 branch with help from Jose Miguel Samper's article and Daniel Fernandez' sample application. I'm very happy with the results (no more placing HTML tags within Java strings) and expect to see Thymeleaf playing a role in more areas of the application. (A minor retirement, as well--I removed the "all blog" planet as it duplicates the front page theme and can anyway be manually created if desired.)
GitHub is reporting that I'm getting a few more people cloning my work since I announced its release, encouraging to see. TightBlog 1.0 was primarily about getting rid of yesterday's lard (and there was a mountain of it.) While there are still several classes that need refactoring or removal, its foundation is much more solid today, a good base for TightBlog 2.0 to build on.
First release - TightBlog v1.0.0 available!
I've found a good point to make my first TightBlog release, and so here it is. I held off on uploading a Java WAR file as TightBlog is primarily for Java enthusiasts who are well acquainted with the concept of
mvn clean install and would presumably rely on that instead of any WAR I provided. After the dependencies (Spring, Struts, etc.) are downloaded, TightBlog takes less than a minute to build, and running
mvn jetty:run from the app folder afterwards will allow you to quickly demo the application at
Some editing enhancements put in over the past week:
These benefits are in addition to the "Notes" field on the blog edit page (to store metadata about the blog entry) I had added a while back.
Stats: 19 fewer Java source files, dropping me to 187, 62% fewer than the original 493 in the Roller release I forked. 209 issues closed, with eight open for the next release. 85K lines removed, with the removal of Xinha accounting for 15K of that. The GitHub contributors page and the OpenHub stats are indicating that, all told, I managed to drop the code about a third in size, even if I somehow sense I managed more than that.
New user administration functionality in TightBlog
Over the past few days I've added some user administration options to upcoming TightBlog:
Administrators can now require all new account registrants to be approved before they are able to log in. Upon a new registration, TightBlog administrators will be sent emails to either approve or decline the account request, with a subsequent response email sent to the registrant informing them that they can now log in or that their request has been disapproved.
This option automatically activates email verification--after registration but before the approval routing the registrant will be sent an email to click on to verify ownership of the email account. This provides administrators higher confidence that the person requesting an account with the stated email address is indeed the email address' owner.
Access rights within TightBlog are of two types: Global roles (one per user) and Weblog-specific roles (one for each blog a user has write access to). The former primarily specify whether a user is a regular blogger or a blog server administrator, the latter define the rights a user has for a given weblog: can make drafts but not publish (Contributor), can publish and handle comments and some design configuration (Publisher), or has full ownership of the blog (Owner)--can change the design templates, invite new members, etc.
I added an additional
Blog Creator global role to the
Admin roles already existing.
Admin remains the same while
Blog Creator has the former meaning of
Blogger. The lone difference between
Blog Creator is that the latter can create new blogs while the former would need to have someone first invite them to a blog with whichever weblog role the inviter desires. This new option is helpful for administrators who have Contributors or Publishers whom they don't see a need to grant create blog rights, or for blog owners they wish to limit to one, already created, weblog.
The system administration page allows administrators to choose
Blog Creator as the default role for new blog registrants, a setting which can be subsequently overridden by an administrator on the User Administration page.
The User Administration page now shows account create date and last logged-in date to help administrators determine dormant accounts that should perhaps be disabled.
TightBlog: June 2016 Update
Continued work on the TightBlog front-end. While TightBlog is not a single-page app, AngularJS is nonetheless playing more and more of a role on the front end for its two-way binding. Backend, I've updated to Java 8 time as well as upgraded to Struts 2.5. About 60% of the UI is now REST-based. I'm expecting "soonish" to make an testing release that I can place my own blog on while continuing to do front-end enhancements. In particular, I'd like to get the comment management screen more streamlined.
TightBlog: May 2016 Update
Heavily working on the front-end, moving TightBlog from a server-side rendering with Struts2 & JSPs to a REST-ful architecture. The Spring Framework is doing wonders in allowing me to easily switch to REST API calls, code is nicely melting away in the process. I've mostly finished updating the server admin screens using JQuery and JSRender/JSViews. I'm trying to find a good point right now where I can do a release, deploy my own blog on it, and then continue on with enhancements & refactoring.
TightBlog: April 2016 Update
A satisfyingly productive month. In particular, the blog page rendering system as well as the default blog templates supplied with TightBlog were cleaned out and nicely simplified. At this time, the application is more or less usable as-is, however, I'll be rechecking the data model as well as making an additional pass through the source files to see if I've missed anything.
Stats: Sixteen more Java source files removed, dropping TightBlog to 231 total. From my commit totals, over 55,000 lines removed from the project through 248 non-merge commits. Seven issues open and 157 closed.
TightBlog: March 2016 Update
Did not get as much done the past month due to work constraints, main gain was in upgrading from Log4j to Log4j2. Right now I'm revamping the template customization functionality, once done I have a modest amount of other UI improvements to put in for the first release. Twelve issues open, 140 closed, 5 more Java source files gone (247 for TightBlog vs. 493 for Roller), and inching towards 50,000 lines (49.2K) removed.
TightBlog: February 2016 Update
Still actively working on TightBlog, but due to time constraints could not work much on the project the first couple of weeks of this period. Mainly internal refactoring, including work on simplifying and consolidating the Pager classes that are used to scroll through lists of blog entries, users, comments, weblogs, etc. I also simplified the former roller.properties to mostly just the common fields that people normally customize (file is now about two-thirds smaller, compare TightBlog's to Roller's). For the many potentially useful but seldom overridden configuration settings, those can now be modified via a Spring XML configuration file placed in the same folder as the user's tightblog-custom.properties file. For the rarely overridden settings, using Spring configuration over a property file nicely simplifies the internal code while not placing much of an additional burden on the relative few who will need to override those settings.
Metrics: 14 issues still open, 138 closed, 199 non-merge (i.e, "real") commits with roughly 47,000 more lines removed than added (as shown on the GitHub Contributors tab), and eight more Java source files removed, dropping TightBlog to 252 total.
|« December 2016|