Search This Blog

Showing posts with label Crap Software. Show all posts
Showing posts with label Crap Software. Show all posts

Friday, May 28, 2021

Disgusting

Adobe, the company, has been releasing RoboHelp for 13 years, per https://en.wikipedia.org/wiki/Adobe_RoboHelp. I use version 2015, which was released on June 8, 2015, a whopping 2181 days (5 years, 11 months, 2 weeks, 6 days ago. Between the release of RoboHelp 2015 and RoboHelp 2017, I started working at my present job and, because of the timing of when I needed to choose a Help Authoring Tool (HAT), I did not have the option to choose version 2017. Fast-forward a few years and Adobe creates a Beta testing program, which is over, for an upcoming version of RoboHelp. I signed up and requested a  Virtual Desktop Instance (VDI) to be set up so as to not disrupt my "Production" laptop. I worked with the Beta version for several months. Last month, when I was issued a laptop to replace the laptop I was issued when I began at my employer, I had RoboHelp 2020 installed on it. The idea was to put that version through one last push of trying to decide whether I should upgrade from RoboHelp 2015 to RoboHelp 2020. My verdict? No, I should not.

The following screenshot shows how lowly RoboHelp is in the Adobe family of products. I didn't blur the screenshot at all. It shows that Adobe is "okay" with releasing a video about RoboHelp 2020 with very poor quality. I am using the "original" size of the screenshot to demonstrate that there was no resizing that could have impacted its quality, which is why it looks grossly huge and cuts into the options on the right.


The image above is from the video below.

I plan to use RoboHelp 2015 for the next 15 years.

Sunday, January 17, 2021

A Dozen Years Later

I wanted to revisit this post now that a dozen years have passed. Neither the original author nor I work at the company with the "colors" issue that is described in this post. Just Because you have a Product to Show

Thursday, August 23, 2018

Wide-Ranging Post Promises to Discuss Broken Promises

A relevant Star Wars Universe quote and me impersonating a Star Wars Universe character to make my point should set the tone for this post:

  1. As Anakin Skywalker said, "If you're not with me, then you're against me." 
  2. As Yoda might say, "Trusting are you too much."
Now, on with the topic. On the ACT Jobs site - https://careers-act.icims.com/jobs/intro - I searched for the word "Pearson" because I wanted to know if any of the ACT job descriptions mentioned working with employees at Pearson - I was curious. During my job hunt in January 2016, if I had found an ACT job with the word "Pearson," I would not have applied since I had just been laid off from Pearson. I was very surprised when I saw the following search result:


I clicked the link and again searched for "Pearson" because there was a search result that made a promise to me that if I looked at that search result, I would find the information I wanted.


It's the same bogus search result I used to see at Pearson when I would search for the word "jetty" and see a search result, only to have a search on the search result be a false promise. In the "jetty" situation, the word is on the page - you just need to expand multiple drop-downs in order to see it and, once you find it, you may think that there is only one instance of the word, but you'd be wrong.


See, no page-level result:


But when you look at the code, Jetty is there:


I think there should never be situations like these examples when a user cannot find the information they are seeking.

Friday, August 18, 2017

It's a Bug!

Saw this while viewing information about one of our credit cards:

Wednesday, August 12, 2015

Questioning the Standard

What's on my mind is not a new topic. In fact, back in 2009, I wrote about a similar topic: the rules for creating software. In 2009, my focus was on the different ways software make user assistance available. You can read that post here. Today, I have a different topic to consider: the manner in which the software developer attempts to communicate information to the user. And, because it's my blessing and my curse to see the mistakes others make, especially when it comes to software development, I feel the need to write about it. After all, working as a technical writer since 2/10/1995 - 20 years, 6 months or 7486 days - has allowed me to experience and use a lot of software. I've learned from the countless user interfaces I've encountered that software has rules.  Unfortunately, not all software developers follow the rules. There's a simple reason for that: the rules are based upon opinion and what someone thinks is a good decision often turns out to not be one.

For example, I opened Photo Move 2 a while ago. This is what I saw:

I clicked No because I didn't want to update the software at that moment in time. Then I saw the following message:

The software didn't open.

If the user really doesn't have a choice, why is the first message phrased as a question? Because most software messages that deal with updating software phrase the initial message about software being out of date as a question. But it's really not a question because if the user doesn't click Yes, the software won't open. In order to use the software, there isn't a choice: upgrade or you can't use it.

So, then, why not simply state that? The first message should read something like, "There is a new update available. You should install it because your current installed version of the software will not run any longer." That's off the top of my head. What I advocate for is to have more truth in warning messages like the ones above. What are the consequences for clicking the buttons? Tell the user what they need to know before they click the button. If the first message had a message like my rewrite, I wouldn't have clicked No. I would have clicked Yes because I would have known that I wouldn't be able to run the currently installed version.

Sunday, March 27, 2011

MEAN F'ng PEOPLE!!!

DO NOT go to Wrestlescoop.com and look for pro wrestling news! One of their links sent me to a site that made ALL my Desktop icons, all my Favorites, and all my Start menu options be set to Hidden. I just now got it figured out after about 1 hour of silent cursing and trying to understand what had happened. I think I have it all fixed now. It's scary as hell to have an empty Desktop when it normally is covered with shortcuts and folders and files. It's also scare to have all your Favorites in your Favorites tab in IE gone. This site describes what was happening.

Saturday, January 17, 2009

Just because you have a product to show for it in the end doesn't mean you succeeded

The development process, no matter what anyone says, is a constant push and pull affair. In my experience, what I think is a good design decision is a negative decision by someone else. What I like, as a user, is brought to the table when I comment on designs and weighs heavily in my impression. For example, I think an Exit button shouldn't mean "go back to the previous screen." It should mean "Quit the program." I've lost track of the number of times where an Exit button, to someone else, means exit the page and return to where you were. I don't understand their perspective and, from the glazed looks I get when I talk about renaming "Exit" with "Cancel" or even "Previous," I often get blank stares.

This whole idea of tug of war in the development process is especially evident in the following e-mail I received from a member of one of the lists I'm on, who will remain anonymous. Bits of what this person wrote sound familiar. I have some comments at the end so read the whole thing:


Subject: Status Update

I am really tired of all this BS. I mean, seriously. We keep on chasing our tail and it's really pathetic. In our last demo, all I heard were complaints about colors. It was announced that we couldn't sell this without a change in the colors. No one liked them the way they are.

I distributed screenshots of the system we were discussing on Monday.

We needed those back on Thursday in order to make our Monday deadline. After a couple emails to remind people about our need for the screens in order to proceed, I finally got a call around 2pm on Friday (Delay #1), asking me to clarify again what I wanted.

I said the screens were there so "quick changes" to the forms could be marked. I said that all we wanted were color changes, wording changes, field positioning/order changes, and anything else simple like that, but no large functionality changes if we were to be able to get this done. We used screenshots for a couple reasons. One reason was to document suggestions and the other was to allow independent work and from the comments received, make a final decision regarding colors.

This approach backfired. Shortly after that call, a member of the Team was pulled from working on his tasks - which are critical to getting test data so we can verify our calculations are correct - and told to meet to talk about the screens. Pulling him from working on his tasks means a delay (Delay #2)

As of Friday at 5:10 pm I had not received a single screen. And the revisions are due on Monday. I went over to the meeting they were having. They were arguing about functionality - nothing to do with colors - and had not yet finished talking about it. I was able to extract about 9 screenshots (1/2 of the total) from their hands with a lot of comments on them.

They told me that for the rest, I would have to wait until they were done meeting on Saturday. (Delay #3) Yes, Saturday.

A meeting among the same people was held on Saturday. It was scheduled for 8 AM. I know for a fact that two of the attendees - including the member of our team - were there for the meeting at 7:45 for the meeting. However, others came @ 9:30 (Delay #4)

Finally, I got the screen shots back around 2 on Saturday - 2 days late.

Here is what they did:
  • First, they didn't do the assignment right. There isn't a single color change specified.
  • Some screens are being reverted back to the ones the team had done back months ago that were rejected.
  • Two screens have a big X through them and the words "Don't Need!"
  • There's some notes about new functionality that must be added. That's *not* a color change!
But far and away the two that really got me were:
  1. These are major changes that they want. The database needs to be changed. In the same breath that I take heat for not meeting our deadlines, we are given changes that will only add more time. I don't know if anyone really gets this: if my deadline is Thursday, and I get the information I need to do my job on Saturday, the deadline has to be extended. It still takes the same amount of time to do my work as it would if the Thursday deadline was met!
    • The program can be released and will work, but doesn't need most of these changes. They are ones that are not critical to our users using the product! BUT they are being made to be critical. I do think these changes absolutely should be done at some point - I agree with them. But why now if our collective goal is to release a product? Does anyone really believe version 1 of these systems will be perfect? There is no reason to think these new systems will be perfect with version 1.0. We haven't even put it through the validation team ringer yet. They will have changes.
    • On a side note, I really have a problem with the way this project has been going. I asked for specs and documentation as a requirement to getting this project done. I have asked repeatedly to have this information. Whenever I mention the word specs or documentation, it seems to be mistaken for a curse word. It's not. They are essential to having a marketable product!
Last week in a meeting, when we discussed this for the umpteenth time I again got the answer, "You asked for specs and I gave you a member of the team that knows the system."

Is this working? The answer is "NO!" This approach to software development is based upon a single perception of the functionality - yet, there's arguments about what functionality needs to be included in these systems?

You know thte biggest kicker? After years of designing and coding for a PC-based product, I'm asked to make it browser-based.

We went through this years ago. No one liked browser-based. There's no way to make a browser-based app act exactly like a PC-based app out-of-the-box without extensive coding. Coding takes time and we're already past our mandated deadline. So, heck, let's just add more things to do before we get these systems to market! There are radically different design considerations, not to mention functional differences between a PC app and a web app? When developers were sent to training, they had a class on PC apps. Who is going to rewrite all this stuff to be a web app? Are we hiring people I don't know about?

This brings up many, many issues:
  • Are we really saying to scrap the UI that was being argued about in the Friday and Sat meetings and redesign all of this as a web app?
  • Why is this being changed now? Why at the END of this project!?!?
  • Why didn't we train people to do web apps if that's what we wanted to do?
  • Why have we not received clearly defined goals and decisions on direction?
And you know, honestly, I'm all for a web product. That's fine. I'm all for the suggested changes too. In fact, I'd be more than happy to scrap the entire front-end and all the code I've spent nights and weekends writing to make development easier if the final decision is that we want a web product.

I'll even do it all without a single complaint. But this nonsense of changing priorities, pulling team members from their tasks, and making these late-in-the-game decisions is not helping us at all. It is making the success of the project in jeopardy.

When such prolific indecisiveness has plagued this project since the start, I'm not seeing any signs of it letting up. I mentioned the other day that if we don't actually plan things, we would fail. Isn't it obvious yet? When I said that lack of planning and documentation would cause us to fail, I meant it to be understood that failure can come in many forms. Sure, it could mean the project doesn't get completed, which would be the most obvious failure, but it can also mean that we miss our time-to-market, we spend too much time on some aspects and end up spending more money for developers to program those aspects than we ever should have. Just because you have a product to show for it in the end doesn't mean you succeeded.


My jaw hit the floor many times while reading that e-mail. I have a few questions:
  1. Will there ever be a version 1.0 in the market of this product?
  2. How long will testing this product in the validation department take?
  3. Will the users like it?
  4. How is a person a replacement for specs? What if that person leaves or is, God forbid, hit by a bus?
If I get any other info re: this person's situation, I'll be sure to pass it along.