Inconsistency Throughout Product

John Ronan
John Ronan
Tenth Anniversary Kudos 5 Name Dropper Participant
in Education Management APIs

Wendy's recent question about contract lists and the fact that you delete/rename them in an obscure, “non-standard” way, got me fired up enough to open a new topic.

My general comment/question on this is, once again, WHY is THIS so DIFFERENT from most of the other ways to handle lists???

This is another example of the many inconsistencies in this system, which requires the user to [re]learn a unique approach to something that should be STANDARD!

Examples abound in all areas of the system. These are the ones that bother me most:

  • Searching for any record:
    • looking for all names beginning with “Mc”, in some places, I can/have to use “Mc%”; in some contexts, that'll return nothing. Sometimes all I need to do is type “Mc”. In some contexts, there is no way to do such a search.
    • Sometimes when searching for a student, you can use email or first name. Other times, it can only be last name.
  • Managing lists - why do contract lists look different from any other kind of list? ["Save As" semantics are either different in different places or don't exists at all [eg. advanced lists]
  • Preview - Click preview while editing an application and you [conveniently] get a new browser tab, which, when you're finished viewing, you can close. But preview a transcript and it displays in the current tab. If you were to close the tab here, you'd lose the editing session of the transcript.
  • Course Record Displays: in some places, “course code” is displayed. In others, it isn't

What others are there? [Perhaps BB is listening]

I wish these would be addressed. They must be low-hanging fruit.

Comments

  • Michael Panagos
    Michael Panagos
    Tenth Anniversary Kudos 2 Name Dropper Facilitator 1

    I just want to add to this that this is not the only inconsistency with Blackbaud SKY API.

    For example, depending on the error that the API responds with, the formatting comes in one of 3 different ways that I've found (so far!) and if you have a modular error catcher in your app you have to account for all 3 different ways. There is no documentation on all the different ways, sadly.

    Another example is pagination. Depending on the endpoint, and I've not even gone through all the School ones let alone other API endpoints such as for RE or FE NXT, you have to specify the next record in one of 3 different ways (next record number, last user id, or next page number).

    This is a trend that hits on many areas and reporting is just another one.

Categories